Multicore Packet Processing Forum

Archive for April, 2010

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

The first part of this post can be found here.

This focus on reducing the size of the TCB is another factor in system designers looking at virtualization solutions as a means of improving the security and robustness of their systems. Given the larger TCB required with a Type 2 hypervisor, it would be wise to stick with Type 1 hypervisors for security-critical networking systems. But there are also significant differences among Type 1 hypervisors. For example, some of these are actually microschedulers that run their guest OS’s as a peer. This means that the guest OS’s also have the ability to directly access physical memory and execute privileged instructions, which means the guest OS’s must be included in the TCB as well.

Lastly, the implementation of the hypervisor is equally critical to the robustness of the system. For example, a design which avoids using dynamic data structures can be more immune to stack-overflow attacks. Also, the scheduler must incorporate safeguards to prevent denial-of-service attacks, which could incapacitate the hypervisor and prevent the fair execution of all VMs.

Since this is multicore-oriented forum, you might be wondering how all of this applies to multicore systems. As you would probably expect, virtualization security in a multicore system is even more critical than that for a uniprocessor system, as typically a far greater number of workloads and end-users will be negatively impacted by any failures or flaw in the underlying hypervisor(s).

Architecturally, there are two ways to implement a multicore bare-metal hypervisor:

• A single hypervisor instantiation per physical CPU core
• A single (SMP) hypervisor for the entire set of physical CPU cores

The advantage to the first approach is that the proven and certified architecture and implementation of the uniprocessor hypervisor can be leveraged, with the changes being limited to the addition of cross-hypervisor communications interfaces, and attention to the implementation code sequences to minimize performance-killing locks. Therefore, it’s easier to maintain high security, and minimize the development time and maintenance. The disadvantage to this approach is that it is not possible to make the multicore CPU appear as a uniprocessor to the guest OS, which is useful for migrating legacy non-SMP enabled OS’s to multicore hardware to increase performance.

Intuitively, the second approach offers the converse benefits and disadvantages: Greater development time and maintenance burden, less maturity and therefore potentially less security, but the ability to emulate a uniprocessor.

In summary, when choosing a virtualization solution for a security-critical networking system, one should begin with providers of Type 1 hypervisors, be careful to ensure that they are true hypervisors (and not microschedulers masquerading as hypervisors), understand how their multicore solutions are architected, and ask a lot of questions about the implementation and the details of its security certifications.

Finally, for those interested in learning more about virtualization and hypervisors, here’s a list of several relevant articles, papers, and a book:

10 questions to ask when choosing a virtualization solution by Casey Weltzin of National Instruments.

Embedded System Security by Frank Altschuler and Bruno Zoppis of TRANGO Virtual Processors.

The gHost in the Machine: Part 1 by Harlan McGhan at Microprocessor Report.

The gHost in the Machine: Part 2 by Harlan McGhan at Microprocessor Report.

The gHost in the Machine: Part 3 by Harlan McGhan at Microprocessor Report.

Virtual Machines by James E. Smith and Ravi Nair.