4 ms·
Judging by the descriptions, these VirtualBox bugs are all in the device emulation, host-to-guest communications framework and so on, so they would apply equall
by pm215 9y ago
Judging by the descriptions, these VirtualBox bugs are all in the device emulation, host-to-guest communications framework and so on, so they would apply equally whether the VM was using virtualization hardware or instruction emulation. This isn't unique to VirtualBox's track record -- the 'attack surface' for a VM is almost entirely in the device models, where software bugs allow VM escapes. The hardware virtualization is much less likely to cause problems: CPU bugs are rare compared to software bugs. In fact I think a pure-emulation setup would be worse off, because there's a lot more potentially buggy software doing the emulation that the guest can try to exploit. If you don't see those in a CVE list it's because nobody's bothering to try to exploit whatever emulator you're using, or because the emulator doesn't promise guest isolation and doesn't track bugs as CVEs. Comparison of raw CVE counts is tricky and risks apples-to-oranges problems.
- bonzini 9y agoCompared to Xen and KVM, VirtualBox runs much larger parts of the device emulation in ring 0, together with the core CPU virtualization code, for performance. This is particularly important when KVM is used with a special user (such as user "qemu") and SELinux, because then a bug in QEMU becomes extremely hard to turn into host root access. Libvirt takes care of configuring SELinux this way for you, when you use for example KVM on OpenStack.