Multicore Packet Processing Forum

By Brad Suessmith – Minah Ventures – Member of Technology Advisory Board

Alex Bachmutsky from NSN posted a series of excellent articles last fall regarding the use cases for virtualization in multicore-based networking systems, along with a review of the various suppliers. As someone who previously worked in the business development side of the embedded virtualization industry, I thought I’d take a moment to write about another critical aspect of virtualization solutions for networking software, and that’s security. Please note that when I use the word “security”, you can replace it (in your mind) with the word “reliability” or “robustness” and maintain the integrity of the sentence, as the characteristics of a secure virtualization product are very similar to those of a reliable one.

First of all, the term “hypervisor” was coined by IBM in the 1960′s to describe the software in a system that performs the virtualization function. There are two broad categories of hypervisors:

• Bare-metal
• Hosted

Bare-metal hypervisors are known in the industry as “Type 1″ hypervisors. In a bare-metal hypervisor, the virtualization layer runs at the highest privilege level in the system, with the guest operating system(s) and other system software running in virtual machine(s) above it at a lower privilege level. A hosted hypervisor, on the other hand, runs “on top” of an underlying operating system, typically at the application or user-mode privilege level, and in turn, supports additional guest operating system(s) above it. Hosted hypervisors are also known as “Type 2″ hypervisors.

The distinction between these two approaches is critical, because, in general, a bare-metal hypervisor will by its nature be more secure (and thus reliable), than a hosted hypervisor. The reason for this is that by running at the highest privilege level, the bare-metal hypervisor can maintain exclusive control over the privileged resources of the CPU. I.e., it has the ability to execute “supervisor-level” instructions, which are used to configure and manage the MMU and caches, configure and process interrupt handling, and generally control the operation and state of the CPU. Obviously, control over these instructions and functions is critical for maintaining the security and robustness of the system. For example, if a rogue piece of code running in one VM is able to gain control over the MMU, it could reconfigure it such that it gave itself access to memory owned by another VM, and thereby compromise the integrity of that VM’s code and data structures. In a properly constructed Type 1 hypervisor, this rogue piece of code, running de-privileged, would be trapped by the CPU’s instruction decoder logic as an illegal instruction, cause an exception to occur, switch the CPU to supervisor mode (highest privilege level), and cause control to revert to the hypervisor. The hypervisor can then process the exception directly, or transfer control to another guest VM/OS exception handler.

A Type 2 hypervisor, running in user mode, has no such ability to prevent rogue code sequences from altering the privileged state of the hardware. A Type 2 hypervisor is totally reliant upon the integrity and robustness of the underlying host operating system. If the host OS is very secure and bug-free, then this is not a problem. However, the general rule-of-thumb in the software security field is that the robustness of a system is inversely proportional to the number of lines of code in its software. Therefore, an OS with millions of lines of code is unlikely to be as secure as a hypervisor with a few thousand lines of code, everything else being equal. Software security experts generally try to minimize the number of lines of code in what is called the “Trusted Computing Base” or TCB, and this TCB is composed of the software that runs at the highest privilege level in the system, and grants privileges to the untrusted code. Assuming a constant bug rate, the smaller the TCB the fewer the number of bugs. Also, the smaller sized TCB lends itself more readily to verification through formal methods and computer-assisted auditing.

Continued on part 2…

One Response to “Secure Virtualization – Part 1”