Life in Code

We hear a lot of different things about KVM being “secure” and “not secure.” Most of the opinions we hear are directly associated with perceptions of security in the Linux kernel. People who have a high opinion of Linux security believe that KVM has high security. People who feel otherwise about Linux tend to also feel otherwise about KVM (that it is not a high-security platform).

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.