* Aggressively compile out unused features/devices.
* Confine each VM with separate SELinux contexts (sVirt).
* Run qemu as a special non-root user.
* Use seccomp to confine the system calls.
* Pass in pre-opened file descriptors to qemu, so qemu doesn't need to open files (helps with writing tightly confined SELinux policy).
* Run qemu in a cgroup.
* Run qemu-img with resource limits.
* Compile qemu with all hardening features enabled like RELRO, PIE, etc.
* Audit the code manually and with Coverity.
* Take security reports seriously and have a fast patching mechanism (you can effectively "live patch" qemu by migrating a VM off the old qemu and on to the new qemu).
Probably more that I've forgotten about ...
Some of our customers are running untrusted VMs in their public clouds using this configuration. Others will be running on-premises virtualization set ups with VMs from across their companies which can be equally risky.
SELinux is probably the most important mitigation in the list, and while it has a bad reputation that's mostly from people who haven't used it for over a decade. I have SELinux enforcing on every machine I use, and it rarely causes an issue.
Historic(2015) VM escape example https://venom.crowdstrike.com/
I doubt anyone is wasting a good zero-day on disposable qemu netboot images. Someone may try a venom(like) image for 'fun'.
Given that bugs which have been found in it previously have been fixed, can we know from now on that it’s 100% safe?
As far as I know there does not exist a way of rigorously proving that.
fwiw my interest in theoretical computers and formal verification based on this fundamental aspect.