Microkernel-Based Virtualization Meets Embedded Security Challenges
By implementing virtualization at the microkernel level, developers can build on embedded virtual machine technology as a platform for enhancing security while hosting very different kinds of operating systems.
GERNOT HEISER, OPEN KERNEL LABS
Page 1 of 1
Now more than ever, embedded systems developers and device OEMs face complex requirements for features and functionality in next-generation intelligent devices. In these emerging embedded applications, the size, scope and delivery costs of device software frequently outstrip investment in the hardware on which that software executes. Moreover, these and other devices are increasingly interconnected across wireline and wireless LANs and WANs and to the Internet. This mix of software complexity and connectedness poses significant challenges for device robustness and integrity: complexity leads to more exploitable bugs while connectivity provides more avenues for exploitation.
In a similar vein, responding to growing and pervasive threats to the security of intelligent devices and to content deployed on them, the embedded marketplace is confronting a new wave of security requirements. These emanate from a range of constituencies, including carriers, operators and content providers and ranging up to retail channels, financial institutions all the way to consumers.
Most embedded developers, while familiar with the basics of security, do not possess the expertise needed to “lock down” systems based on traditional RTOSs, on embedded Linux, or other pervasive OSs, if this is possible at all. Developers and OEMs must meet real needs for security, but lack the tools to secure their device applications.
Introducing Embedded Virtual Machines
System virtualization technology provides a software environment in which several “guest” operating systems can run as if each owned a complete hardware platform. Such virtual machines (VMs) abstract available system resources (memory, storage, CPU core(s), I/O, etc.) and present them in a regular fashion, such that “guest” software cannot distinguish VM-based execution from running on actual physical hardware. The VM is implemented by a software layer called virtual-machine monitor (Figure 1). This virtual machine monitor is sometimes popularly referred to as a hypervisor, but in this context we reserve that term for a more specific function.
Virtualization is a “killer app” enabler in the enterprise and on the desktop, conferring benefits in load balancing, server consolidation, legacy code migration, cross platform interoperability, and also security. In the last two years, virtualization has also made key inroads in embedded applications.
Contrary to the enterprise, virtualization in embedded systems is motivated by the co-existence of a fixed set of vastly different operating systems (low-level bare-bones RTOS and high-level application OS) rather than the dynamic creation and destruction of similar OS environments. Other motivations are architectural abstraction and, increasingly, security.
Virtual Machines as a Security Platform
In the enterprise, IT managers employ virtualization to realize two types of secure computing: as a safe “sand-box” in which to let loose and study viruses, worms and other invasive threats, and as a means to limit damage and response degradation inflicted by denial-of-service (DoS) at-tacks, by isolating and throttling (virtual) machines that host the targeted servers and services.
In embedded applications, developers can also benefit from virtualization as a security tool by using it to isolate application OSs, like Linux, BSD or Windows, from the relatively defenseless RTOS, which runs the critical real-time environment.
The primary mechanisms by which virtual machines improve security are the segregation of guest OSs into individual virtual machines, enforced by CPU operating modes (privileged/non-privileged) and memory management units (MMUs). This involves explicit communication channels between VMs with network-like mechanisms.
These applications of virtualization are of limited use in many embedded systems due to their resource-constrained nature. It is inherent in VM technology that each VM looks like raw hardware, and needs an OS to support any software. The resource impact of each VM is therefore significant, and most embedded systems can only support a small number of them. Furthermore, the VM model of inter-VM communication, (virtual) network interfaces, is fairly heavyweight and does not match the tightly integrated nature of embedded systems. These limitations mean that an appropriate technology for embedded systems must go beyond virtualization in the tradi-tional sense.
Microkernel-based virtualization provides a good match to the requirements of embedded systems, as we will see later, after a look at other approaches to embedded virtualization.
The term “virtualization” is frequently used as synonymous to virtual-machine technology. However, virtualization is far more general, and this can create confusion. A VM (also called a “system VM” to distinguish it from “process VMs” such as Java virtual machines) virtualizes a complete computing platform, consisting of processor, memory and peripherals. System virtual-ization is what provides the encapsulation that can be leveraged for security. Approaches that virtualize less than the complete platform do not have these benefits.
Modern microprocessors offer at least two modes of program execution (a.k.a. rings)—system mode (privileged) and user mode (unprivileged). To enjoy any security benefits from deploying VM technology, all guest execution environments must host OS and program execution exclusively in user mode, as otherwise the (potentially compromised) guest OS can break out of its “cage,” negating all security benefits.
Some system software labeled as “virtualization” implements only rudiments of virtualization. A prevalent example is the virtualization of only the interrupt chain. In this scheme, a rudimentary hypervisor selectively fields interrupts and (re)directs them to one of two “guest” OSs that are otherwise co-located in a single memory map / execution space. The main application is to enhance the real-time responsiveness of an application OS like Linux by handing over real-time operations like baseband or multimedia processing, to a co-located RTOS (Figure 2).
Clearly, such an approach, which runs the guest OSs in system mode and is more correctly described as “OS co-location,” provides no security benefits whatsoever. It also complicates de-bugging, QA and support.
Some co-location products provide the option of “isolated” guest execution, at the expense of reduced performance. Promoters of these platforms argue that the virtualization cost should only be paid where it is necessary for security. Given the massive amounts of code running in system mode on such systems (and thus the huge size of the trusted computing base (TCB)), security is weak at best. Furthermore, the overhead of well-designed virtualization platforms is low enough that it does not make sense to trade away security for performance in this way.
Microkernel Functioning as a Hypervisor
Traditional VM technology uses a monolithic hypervisor, running in system mode, which performs all virtualization operations, manages all resources and enforces security. Device drivers are part of the hypervisor, making it quite large. The advantage of this approach is that any virtualization event only requires a single hypervisor invocation, similar to a system call in a traditional OS.
Alternatively, a special VM (often called Dom-0) runs a trusted guest OS containing the drivers, which reduces the size of the hypervisor but expands the size of the TCB (by the trusted guest) well beyond the size of a traditional hypervisor. Virtualized I/O operations in this approach require communication with Dom-0.
A variant of the second approach is the use of a microkernel as the basis for the hypervisor. A microkernel is a generic platform on which arbitrary systems can be built. It is characterized as only containing code that must execute in system mode, and only providing general mechanisms, no actual services. Any service is implemented as a user-mode server, running in a normal, unprivileged address space. In such an approach, some of the virtual-machine monitor code is itself in user-mode components, as are all device drivers (Figure 3).
The Microkernel Advantage for Embedded Virtualization
One advantage of the microkernel approach to implementing virtual machines should be obvious from the above: the privileged code is minimized, which is good for security. There are other advantages, which result from the small size of the kernel, its high-performance communication primitives, and its generic nature.
The traditional strength of virtual machines, and the main reason for their popularity in the enterprise space, is their strong separation. In embedded systems, however, communication between subsystems is frequent and critical for performance. Hence, a set of robust, secure, lightweight and fast communication channels for inter-partition communication is required, beyond the VM-style communication via virtual NICs.
A modern microkernel provides ultra-fast message-passing primitives, as well as the ability to set up shared-memory regions for zero-copy bulk data transfer. In order to maximize security, all inter-partition communication, whether by message passing or shared memory, must be subject to a security policy that can be tailored to the requirements of the particular embedded system.
In embedded software as in human intelligence operations, the key to tight security is compart-mentalization. While it is tempting to give a single guest exclusive dominion over I/O, or to divide peripheral interfacing between two contexts, trusted and untrusted, the greatest security benefit arises from isolating access to physical memory address and memory-mapped I/O down to individual devices. Rather than assigning I/O devices and streams to individual guest OSs, per-device isolation confers the greatest security and also supports selective and secure sharing of I/O among guest OSs. This is achieved by isolating drivers into individual address spaces, and mapping to each driver only the registers of the device it controls.
As a means to substantiating supplier and developer claims for software and system security, OEMs increasingly look to security standards like the standard Common Criteria for IT Security Evaluation, ISO/IEC 15408 (a.k.a. CC).
While virtualization does not itself confer particular levels of CC conformance, a microkernel-based hypervisor platform greatly facilitates security evaluation and certification by reducing the scope of the TCB to manageable, verifiable and testable code sets. It also enables minimal, well-defined communication channels among partitions, subject to a security policy that is defined as a user-level component. This means that the security policy can be adapted to a particular use case without changing the kernel—and thus without re-certifying the kernel.
This line of thinking leads to what is arguably the strongest advantage of a microkernel-based approach—the potential for complete formal verification using a mathematical technique called a refinement proof. The microkernel is small enough that it becomes possible to construct a mathematical proof of the correctness of its implementation (in other words, a proof that the C/assembler code correctly, without bugs, implements its specification). A refinement proof goes well beyond the requirements of CC, even at the highest evaluation level, as shown in Table 1.
As the microkernel only provides mechanisms—no services or policies—it is a generic platform resembling hardware; the same microkernel can be used without change in many dramatically different application scenarios. This is a key prerequisite for making formal verification feasible. The expense of the proof is only needed once.
Virtualization, until recently a technology targeted only at enterprise and desktop, today finds expanding roles in embedded design. While providing a versatile platform for legacy code preservation and migration, hardware consolidation, system resource management and sharing, probably the greatest benefit conferred by virtualization on embedded systems design lies in en-hancing security. A range of security and trustworthy computing capabilities are inherent in embedded virtualization, but only by building on microkernel technology can a virtualization platform adequately and effectively meet current and emerging needs for embedded security.
Open Kernel Labs