Hacker News Reader

Comment by snowpanda | Hacker News Reader

What is the alternative to using Virtualbox besides buying a separate computer? I'm assuming there's more vulnerabilities to be found.

View on HN

On Linux, qemu/kvm works well enough for most purposes, on FreeBSD you have bhyve. OpenBSD's vmm is a thing, but I do not know if it can host other systems than OpenBSD, yet.

On Windows, there is Hyper-V. I have only very little experience with it, but in my short time, I did not encounter anything I would like to complain about. I am not sure, however, if it comes with the client editions of Windows. Microsoft Virtual PC still exists, too.

Xen is also a thing - run Dom0 as your desktop system, and run the VMs in the background.

None of this is perfect, but if you need them, there are alternatives.

> Microsoft Virtual PC still exists

Not updated in almost 10 years, not supported on Windows 8 or 10.

I'm pretty sure the Virtual PC product went on to become Hyper-V.

Some of the Xen technology went into Hyper-V. Microsoft had a partnership with the Cambridge labs.

My understanding is that Hyper-V replaced Virtual PC and was not based on it.

shudders Okay, that explains the vague feeling I had that something was not right with this one.

> I am not sure, however, if it comes with the client editions of Windows. Microsoft Virtual PC still exists, too.

It's in Windows 10 client editions too. Look under "Turn Windows features on or off". Windows Subsystem for Linux is there too.

Not on the Home edition or whatever it's called.

Do you know if it can be installed on Home even if it's not part of the standard installation media?

No it can't be.

There is no particular reason to expect that qemu has any greater security that vbox. All of these systems have a significant amount of very critical code; I particularly sceptical of the hardware emulation part.

AWS recently started moving from a custom Xen to a custom KVM, but it doesn't seem it was for security reasons. Xen certainly is heavily used by public cloud providers.

QEMU is huge, but you choose what parts to use. If you stick to the defaults, e.g. your VM has one or more virtio devices, a virtual USB3 controller and USB tablet, maybe an IDE/AHCI controller and an e1000 or rtl8139 NIC, it should be pretty okay.

Because of its use with KVM, QEMU has had its code scrutinized quite closely in the last few years. There are some device models that have a pretty bad track record, such as Cirrus VGA, but they are not the default anymore and there's no reason why you should use them.

Virtualization capable hardware required though (I don't know about Hyper-V).

> What is the alternative to using Virtualbox

Any other hypervisor. QEMU/KVM, Xen, VMWare, and Parallels all have good track records.

Xen doesn't: https://www.cvedetails.com/vulnerability-list/vendor_id-6276...

Xen has a very responsible track record; they communicate clearly the scope and detail of vulnerabilities.

This skews the CVE stats significantly since the kernel developers (aka kvm) rarely actually request CVE ids.

Ehm, I always request CVE ids. KVM has had no serious VM escape in quite some time.

> I'm assuming there's more vulnerabilities to be found.

This also holds true for the alternatives.

I was going to recommend Bochs, which doesn't use virtualisation hardware at all and is instead an instruction-level emulator (much slower but should theoretically be more immune to hardware virtualisation bugs), but then there's this:

https://www.cvedetails.com/vulnerability-list/vendor_id-2505...

Better than this though:

https://www.cvedetails.com/vulnerability-list/vendor_id-93/p...

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.

Compared 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.

Vmware Workstation or Player (on a Mac Fusion) on Linux workstation. Rock solid

There are VirtualBox alternatives, but the advantage of VirtualBox is your exported VM appliances may be imported to the same hypervisor on Windows, Mac, FreeBSD, Solaris, Illumos, and Linux.

VirtualBox also has a slicker UI compared with QEMU/KVM on linux & bhyve on FreeBSD/Mac & vmm on OpenBSD.

The alternatives all have their own merits, but if people are wondering why anyone would use VirtualBox, I believe the above reasons are why.

Reply on news.ycombinator.com