-
The most widely deployed mobile virtualization solution
Data Sheets
Open Kernel Labs Blog
March 31, 2009
Component isolation, hypercells, and address spaces
Recently an OKL4 community member asked why OKL4 offers two concepts to isolate programs, address spaces and hypercells. I can see why there may be some confusion about the relationship between address spaces and hypercells so the goal of this blog post is to make things super clear. You will have to let me know how well I do.
Firstly, to clarify terminology: "Secure Hypercell", "Hypercell", and "Cell" are all synonymous terms, and are used to denote a distinct secure partition of an embedded system (more on this shortly). "Secure HyperCell Technology" means the underlying technology infrastructure within OKL4 that enables the system designer to create Secure HyperCells (or, more simply, to create cells).
Address spaces, as most of you know, are a mechanism for providing isolation between software programs. Many operating systems, running on processors with MMUs, use the MMU's ability to manage multiple address spaces in order to place a program in its own address space and isolate it from other programs running in other address spaces.
What then is a hypercell in an OKL4 system? A hypercell is a higher level abstraction for a component of an OKL4 system to which certain resources and rights are allocated. OKL4 systems can be composed using several types of components. A component may be a single program, in which case from an address space isolation perspective it involves a single address space. However, the real power in Secure Hypercell technology arises from the fact that a component (a cell) can be created at several levels of granularity - from an individual device driver or operating system component, to a program (a "native OKL4 application"), and all the way up to a full virtualized high level operating system (such as Linux) and applications. In the latter virtual machine case, the cell obviously contains numerous address spaces (one for each program executing within the VM). The ability to componentize your system in this manner was a primary motivator in providing the Secure Hypercell abstraction (and, I'd note, it's unique to OKL4. Other hypervisors provide componentization only at the highest level of granularity (virtualization, or full VM's), which provides much less flexibility.
The need for Hypercells as well as address spaces becomes clear when you understand the very flexible form isolation takes in an OKL4 based system. When the only tool you have at your disposal when addressing isolation requirements is address spaces, you are left with only two choices. You can isolate two things in different address spaces or you can forgo isolation and place them in the same address space. OKL4 offers a much more flexible approach, allowing the designer to implement a wide range of policies between these two extremes. OKL4's Secure Hypercell Technology utilizes capabilities as well as address spaces to offer this flexibility.
A capability represents a token for an operation on a system object, and conveys both the right for the holder of the token to perform the operation, and the totality of the knowledge that the holder requires of the system object. This limitation of knowledge is a fundamental aspect of secure communication: system object identifiers (such as thread identifiers) are not global in scope, and the only knowledge a component of the system can have about any other component, including its existence, is via the explicit granting of a locally-scoped capability to that component. No operation, knowledge, or communication with a component is possible without the granting of a capability.
Capabilities are stored in capability lists (or "clists"). An address space is associated with exactly one clist; a cell can contain multiple clists, and a clist can be shared by many address spaces within a cell. For those who are used to the address space abstraction, you can think of this as a complementary "capability space" abstraction: where address spaces are useful for partitioning and abstracting physical memory, capability spaces are a powerful concept to partition the security of your system.
Having hypercells in an OKL4 system supports the complementary concepts of virtualization and componentization. While address spaces are useful to provide isolation between individual programs, cells operate at a higher level: isolation between individual components within your system. A component can indeed be a single program, in which case (from a memory isolation perspective, at least) the cell abstraction is analogous to the address space abstraction (the cell would contain a single address space). But unlike an address space a cell can contain a more complex component such as a full virtual machine.
The combination of cells and capabilities extends what you could do with address spaces alone to include the ability to strongly isolate your components at multiple levels of granularity, and then to be able to select, in an extremely fine grained manner, what level of interaction is possible between those components.
In summary:
- Technically: A system can contain multiple components in the form of cells. A cell can contain multiple address spaces and multiple capability lists. There is a 1:many relationship between a capability list and an address space (an address space is associated with a single capability list; a single capability list can be associated with multiple address spaces).
- Conceptually: Secure HyperCell Technology provides a very powerful abstraction to componentize your embedded system at multiple levels of granularity, from individual drivers all the way up to full virtual machines, while giving the system designer very fine-grained control over the security of the system. The ability to do this is fundamental to the construction of secure embedded systems.
Secure HyperCell Technology is at the core of OKL4's innovations in providing the world's most advanced embedded hypervisor, and I would certainly welcome any and all further discussion on the subject.
Posted by Josh Matthews on March 31 at 11:45 PM
blog comments powered by Disqus
About Josh Matthews:
Josh Matthews, Field Engineering Manager, works with customers delivering on-site training and implementation for OK Labs. Josh recently relocated from the Sydney office to Baltimore, MD bringing along his two rabbits. In his spare time, Josh enjoys a good beer and editing his wife's thesis papers (necessarily at the same time).