Re: Difference between hypercells and address s paces

[XavierL]

Thank you for your verry detailed answer Josh, these 2 concepts are much
clearer to me.

Xavier.

-----Message d'origine-----
De : Josh Matthews [mailto:[hidden email]]
Envoyé : mercredi 25 mars 2009 21:11
À : [hidden email]
Cc : [hidden email]
Objet : Re: [okl4-developer] Difference between hypercells and address
spaces


I'd like to thank Xavier, Geoff, and Cheng for the feedback regarding
Secure HyperCell Technology. I hope in this developer post to completely
clarify the concept and give some insight into why a Secure HyperCell is
an extremely useful abstraction to simplify the design and development of
secure embedded systems.

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).

The original question was "why are there two concepts to isolate
programs"; i.e. why do we have this cell abstraction when we also provide
the usual address space abstraction that is common in most operating
systems?

The first part of the answer relates to 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. i.e.
A cell contains a single isolated system component. 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). However, the
real power in Secure HyperCell technology arises from the fact that a
component (a cell) can exist at several levels of granularity - from an
individual device driver or operating system component (such as a file
system), to a program (a "native OKL4 application"), and all the way up to
a full virtualized high level operating system (such as Linux). In the
latter virtual machine case, the cell obviously contains numerous address
spaces (one for each program executing within the VM cell). 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 is quite unsuitable
for embedded systems).

The second part of the answer relates to security (i.e. the "Secure" in
"Secure HyperCell"), and this really strikes at the core of why
hypervisors that provide only full granularity componentization are
unsuitable in embedded. Embedded systems are highly integrated - as an
easy example, you're obviously going to be sharing most devices between
higher level components - and this integration implies that a level of
communication is required between components. However, you don't want the
requirement for communication to undermine your requirement for security.
What you really want is the ability to strongly isolate your components at
multiple levels, and then to be able to select, in an extremely fine
grained manner, what level of interaction is possible between those
components.

Secure HyperCell Technology provides this ability in the form of
capabilities. 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, along with 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.

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.

Best regards,

Josh

--
Josh Matthews | Field Application Engineer
Open Kernel Labs
t [phone] e [hidden email]
www.ok-labs.com


On Mon, March 23, 2009 5:29 am, [hidden email] wrote:

> Hi,
>
> I don't understand why there are 2 concepts to isolate programs in OKL4.
> Why is it possible to have more than one address space in a hypercell?
> Can someone explain me the purpose of each concept or give me a link to
> some documentation?
>
> Best regards
>
> Xavier Langellier.

_______________________________________________
Developer mailing list
[hidden email]
https://lists.okl4.org/mailman/listinfo/developer