> most stock QEMU-KVM deployments simply run qemu as root with no extra sandboxing or MAC like SELinux/sVirt.
This is not true. OpenStack uses Libvirt for example, so on Red Hat/CentOS systems it will be hardened with SELinux by default. The same is true for virt-manager, which runs as either an unprivileged "qemu" user or as the user that invokes it.
Not all the code in QEMU is of identical quality, but the subset that is used by cloud providers is very mature and is also tested in Google's open source fuzzing cluster. Thanks to a student from Boston University who came up with some pretty cool techniques, we can cover devices effectively without having to teach the fuzzer about each device's registers.
> many cloud providers use KVM-the-kernel-module, but an in-house replacement for QEMU.
Two of them--certainly they are the big ones, Amazon and Google, but pretty much everybody else is using QEMU. For what it's worth, Amazon is also using QEMU on their old Xen-based instance types.
Firecracker is the only open source virtual machine monitor that cloud providers use in production apart from QEMU, as far as I know. It's a very interesting project and the people behind it have also started rust-vmm, a library of Rust crates for virtual machine monitors and device emulation backends. Several QEMU developers also contribute to rust-vmm, focusing especially on the abstractions needed to avoid unsafe code in virtual machine monitors. There was already an instance last year of problematic unsafe code in Firecracker that wouldn't have been there had it used rust-vmm's vm-memory crate, and in fact Firecracker has since switched to vm-memory. So there is plenty of collaboration between the authors of various VMMs.
> Thanks to a student from Boston University who came up with some pretty cool techniques, we can cover devices effectively without having to teach the fuzzer about each device's registers.
Can I ask who this was and is there any more info on their work? Seems important and worth naming them :)
> most stock QEMU-KVM deployments simply run qemu as root with no extra sandboxing or MAC like SELinux/sVirt.
This is not true. OpenStack uses Libvirt for example, so on Red Hat/CentOS systems it will be hardened with SELinux by default. The same is true for virt-manager, which runs as either an unprivileged "qemu" user or as the user that invokes it.
Not all the code in QEMU is of identical quality, but the subset that is used by cloud providers is very mature and is also tested in Google's open source fuzzing cluster. Thanks to a student from Boston University who came up with some pretty cool techniques, we can cover devices effectively without having to teach the fuzzer about each device's registers.
> many cloud providers use KVM-the-kernel-module, but an in-house replacement for QEMU.
Two of them--certainly they are the big ones, Amazon and Google, but pretty much everybody else is using QEMU. For what it's worth, Amazon is also using QEMU on their old Xen-based instance types.
Firecracker is the only open source virtual machine monitor that cloud providers use in production apart from QEMU, as far as I know. It's a very interesting project and the people behind it have also started rust-vmm, a library of Rust crates for virtual machine monitors and device emulation backends. Several QEMU developers also contribute to rust-vmm, focusing especially on the abstractions needed to avoid unsafe code in virtual machine monitors. There was already an instance last year of problematic unsafe code in Firecracker that wouldn't have been there had it used rust-vmm's vm-memory crate, and in fact Firecracker has since switched to vm-memory. So there is plenty of collaboration between the authors of various VMMs.