We also sometimes hear disparaging opinions of KVM security based on mis-information. Such as that KVM is a “hosted” hypervisor or that it doesn’t use hardware security mechanisms.

Mostly, however, we notice that people don’t have first-hand specific knowledge about KVM’s security features. That’s why some of my colleagues at IBM and I wrote KVM: Hypervisor Security you can Depend Upon. This white paper covers the mandatory access control (MAC) features, security certifications, and secure design elements of the KVM hypervisor. For example, KVM is the only x86 hypervisor to support MAC by default. KVM leverages processor virtualization instructions to enforce guest isolation.

What the white paper does not cover are the secondary issues of coding errors, code review, white and black-hat hacking, and maturity. These are are security issues that transcend specific mechanisms but are related to overall design and implementation. (For example, in 2011 there was a programming error in the Linux kernel that subverted SELinux MAC.)

There are some good things to be said about KVM beyond mechanisms. The KVM code base is carefully and openly reviewed. And its older, more mature code than VMware ESX. In The evolution of an x86 hypervisor the authors who are VMware engineers discuss the substantial re-write and re-design of VMware ESX to support 64-bit operation.  From a code maturity perspective, KVM is older, more mature code than VMware, even though KVM is a newer hypervisor.

This is a discussion that isn’t going to end with a white paper.

There is some content that covers the System X EX5 servers – which you can configure with up to 80 cores and 6 Terabytes of RAM. This is unmatched today on x86 hardware except for some speculative designs. The EX5 architecture uses Intel’s own processor bus to extend the memory and I/O bandwidth of the platform without any material performance penalties.

Red Hat – IBM Webinar KVM and REHV

One particular quote (two years old) from Andi Mann is wrong on virtually every point:

“Xen is run and managed at a lower level (ring 0), even for new virtual machine creation, and guests do not share memory blocks, CPU instructions or any of the underlying (albeit occasionally de-privileged) Linux operating system like KVM does. This means KVM suffers performance, latency, security, scalability, isolation and other issues that do not affect a true bare-metal hypervisor.”

Let’s take these claims one at a time:

1. “Xen is run and managed at a lower level (ring 0).” This is egregiously wrong – KVM is run and managed at Ring 0 as are all hypervisors that use Intel VMX or AMD SVM instructions. See slides # 8 and 19 in my presentation kvm-not-what-you-heard or any recent systems’ programmers guide from Intel or AMD.
2. “Guests do not share memory blocks, CPU instructions, or any of the underlying Linux operating system like KVM does.” This is also egregiously wrong. Xen guests share memory blocks with Xen paravirtual I/O drivers, which are almost always hosted in the Linux Domain 0 kernel and shared among all guests. The vast majority of all Xen guests all share an entire Linux operating system — Domain 0– that does all I/O and device emulation. The vast majority of all Xen guests share common device drivers. They share the same code emulator. Even the very few Xen geusts that use the Stub domain code share memory blocks with each other and with the Xen kernel using Xenbus. KVM guests also share code, device drivers, and memory blocks. This is not a problem, it is normal, accepted kernel engineering practice. All widely used kernels do this. It is secure because of hardware memory protection.
3. “KVM suffers performance, latency, security, scalability, isolation, and other issues that do not affect a true bare-metal hypervisor.” First of all, KVM is a true bare-metal hypervisor. But that doesn’t prove anything, because bare-metal hypervisors may also be vulnerable to “latency, security, scalability, isolation, and other issues” if they are mis-designed or if they suffer from programming errors. So this statement is meaningless. The fact is that KVM has performance advantages over both Xen and VMware (see SPECVirt results, for example.) Xen has a huge isolation issue with Domain 0 (See slides #20-23 in my presentation referenced above).

You should dismiss factual errors, such as the ring 0 statement, out of hand. You should disregard these further statements by Mann unless he provides evidence, data, or explanation.

Abstract:

Mike will review myths, misstatements, and mistakenly-held notions about KVM, the Linux hypervisor. Starting with the major one: that KVM is not a “bare metal” hypervisor. In addition to the “not a bare metal hypervisor” myth, I’ll also address other prominent myths, including: KVM is not good at running Windows guests, KVM is not as secure as other hypervisors, KVM does not scale, KVM does not over-provision memory and KVM doesn’t have VM_* (meaning VMware apis or features). Whenever possible, I will show the source of the myth and debunk it using source code, published benchmarks, or other mechanisms.