The name KVM is a bit confusing. It doesn't do anything fundamental different than VirtualBox. The difference is that KVM comes by default with any Linux. VirtualBox ships it's own Linux kernel module for that. That has drawbacks. You typically can't use the newest Linux or the newest features.

KVM also always has the hottest new (performance-relevant) features, because Intel and AMD will always build their hot stuff into KVM first.

You can’t use virtualbox’s kernel module and kvm at the same time. This basically means that you can’t use virtualbox and qemu at the same time.

If you use virtualbox with this new backend, you can use it concurrently with qemu (and a few other virtualisation tools).

KVM is also part of Linux itself, so there’s a lot less haste with setting it up.

virtualbox drivers are/were a constant source of kernel panics on MacOS and Linux too, so that should not be underestimated.

IIRC they also disabled ASLR kernel wide.

Additionally, and perhaps less important: USB3 is a commercial feature of virtualbox, there are stories of companies getting C&D letters (or Audits/Invoices) from Oracle because a developer had installed the virtualbox extensions..

Starting with VirtualBox 7, USB3 no longer requires the commercial extension pack but is part of the OSE release. See https://github.com/cyberus-technology/virtualbox-kvm/blob/de...

I wouldn't call it kernel based. It's not like this is an in-kernel emulation. I would stick with hardware virtualization.

KVM is a userspace API, and kvm-intel/kvm-amd are the drivers for the hardware.

You will be using hardware features. That's also why it is in the kernel: nothing but the kernel should have full unlimited access to the CPU to set this up.

So you could say it must be in kernel to keep the kernel secure. And the performance benefit is "just" exposed hardware features.

The kernel does not provide additional things. As far as I understand: you set up a dedicated memory space and handle traps that halt the execution e.g. when the VM talks to the PCI bus. (It's been a while since I looked this up)

But you need the pieces, especially virtual PCI devices. That's where qemu or VirtualBox enter the scene (or minimalist systems like firecracker). They provide a repository of virtual hardware and all the auxiliary methods to boot a virtual machines. You also need to emulate something like a BIOS or UEFI.

You can think of it as your CPU removing the need to emulate the very same CPU (and a memory controller). You still need to emulate the rest though! But running on the same CPU removes most performance penalties. You run at native speed.

Newer generations can even nest this. Having virtual machines in virtual machines. That's mostly useful for cloud environments so that the cloud provider can run kvm based VMs and you are still able to run VMs inside that VM.

there's no "keeping the kernel secure" and "allowing access to the hardware".

in security research, you either run your samples in qemu without even kvm or you don't.

if in the past they already were using a kernel module then your reply doesn't explain anything.

So they went from using hardware virtualization (provided by intel/amd) with their kernel module to the KVM one. I don't know which benefits it brings

Without being at all up to date on the current state of things, the Virtual Box third party kernel module was historically of famously poor quality[1], even putting aside the general pains of third-party kernel modules.

[1] https://www.phoronix.com/news/OTk5Mw

That clarifies some things and gives me some tails to chace after! Thanks for the detailed response!