Details:

(Details about why we are really there)

What: OK Labs Meet-up in conjunction with Linux World

Where: 661 Howard Street (right behind Moscone Convention Center) San Francisco

When: 4pm Tuesday, August 5, 2008

While in the introduction they pretend to be talking about system virtual machines, later on it becomes clear that the setup they are describing runs at least the RTOS and all code running on top of it in privileged mode (and most likely the Linux kernel too, at least this is what some of the text, as well as their Figure 2 seems to imply). A "virtualizer" switches between the Linux and RTOS environments on interrupts.

This is clearly not "system virtualization". In system virtualization, according to the definition accepted since the '70's, the hypervisor is in control of all system resources, and virtualizes them for the virtual machines, which are fully isolated from each other. By implication, all guest operating systems inside virtual machines are running de-privileged. Our competitor's "virtualizer" clearly violates this. All that is virtualized there are interrupts, not the complete system. The effect is that all guest OSes, plus all code running on the RTOS, must be trusted.

Why are they doing this? Well, the article argues that it is needed to meet performance requirements, including "sub-10 microsecond switch time".  OKL4 easily achieves "sub-10 microsecond switch time" without any shortcuts that undermine security.

Another interesting point in that article is that it argues that running Linux and RTOS side-by-side makes the RTOS code "free from the constraints of the GPL". This implies that the "virtualizer" encapsulates the GPL. Does it? Given that Linux, RTOS and virtualizer are all linked together and run in a flat address space, this certainly seems an adventorous claim. It seems at least as dodgy as the use of binary drivers for circumventing the GPL, which open-source guru Bruce Perens considers "legally ambiguous". If I was concerned about isolating my proprietary IP from GPL code, I wouldn't want to rely on such dubious means.

So, why would anyone buy that system?

Yes, there's a convergence, but it's mostly the hypervisors that are changing. Microkernels have been successfully used as hypervisors
for over ten years (L4Linux was done at Dresden and published in '97). In x86 space, L4Linux has had roughly the same performance as
XenoLinux. And, of course, OKLinux running on OKL4 represents the cutting edge of virtualization technology for embedded systems.

On the other hand, hypervisors are definitely (albeit slowly) becoming microkernel-like. People are becoming sensitive to the size of the
trusted computing base, and the VM people are waking up to the fact that as the use cases for virtualization increase, high-performance
communication (the traditional strength of microkernels) is becoming a critical requirement. I've heard two keynotes last year where VMware-founder Mendel Rosenblum was describing his vision for virtualization. If you listened to his arguments carefully, it was obvious that the
implication was that the hypervisor was turning into a microkernel.

The embedded space is likely driving this, as the traditional VM model (with its implied strong isolation) isn't appropriate there.

So, yes, there's a convergence. Hypervisors are turning into microkernels. OKL4 is already at the convergence point.

Check out the pictures

For the first time, OK is making available a suite of unit tests that tests OKL4 microkernel functionality.  This project is the perfect target to use when bringing up a new port of OKL4 as it removed iguana from the equation and therefore allows you to get up and running more quickly.

Only a minimal set of SoC device functionality (serial for debugging output, timer and interrupt controller) is required.  Plus each unit test narrows focus on a particular subset of kernel functionality, so it's much easier to incrementally build up support for a new SoC.

See Benno's video for more info: http://media.benno.id.au/porting-okl4-new-soc_pal-highquality.mov . <http://media.benno.id.au/porting-okl4-new-soc_pal-highquality.mov>

We are excited to be able to provide these features to the growing Community and we hope you enjoy them.

Tim

Come hang out with fellow developers, down a few beers and enjoy the general OK debauchery.

Here's where we will be:
REDOAK Boutique Beer Cafe
201 Clarence Street, Sydney
t- 02 9262 3303

Hope to see you there!

"In a secure processing environment it is important to keep the code size, and hence the 'attack surface' as small as possible."

At the surface, this looks like our TCB size matters argument (and small is beautiful in this case). But we tend to talk about the TCB size in terms of lines of code (LOC), while this quote talks about (executable) code size (in kB). Somehow this implies that the actual bytes of the executable code are the targets of an attack.

This notion would have merit if the attack was done against the physical storage medium with cosmic rays o or something the like. In the more likely scenario of attacks aiming to exploit bugs in the code, this line of argument is obviously complete nonsense.

Since attacks are against bugs, it's the complexity of the source code that matters. And how is that measured? To a first (very coarse) approximation in LOC.

If we look beyond the first-order effect of source-code size, other complexity effects become relevant. These include the underlying complexity of the task at hand—for hypervisors we can assume this to be the same for all implementations. But another important one is the implementation language: some languages are more error-prone than others. C (which is what we are using) isn't particularly great in this respect (type-safe languages are much better). But one language that is definitely massively worse is assembler. Which happens the implementation language of said competitor.

Since the competitor's implementation uses only assembly language, we can safely assume that their LOC count is higher than ours. Furthermore, the fault density is likely to be significantly higher than ours, for two reasons:

1. assembler code is inherently more error-prone than C code (as C has at least some rules the compiler can check)
2. C code can be analysed with static analysis tools. Such tools have gained significant power over the years, and are quite successful to find many classes of programming bugs. OK Labs uses a variety of static analysis tools (we'll talk about this in a future blog), and that's even before deploying formal verification. People who program in assembler can't use any of this.

So, which code would you trust for your security-critical applications?

Delve into the world of embedded virtualization, and software security in mobile devices with Gernot Heiser and Rob McCammon. In today's connected mobile devices, the OKL4 open source microkernel can provide security, virtualization, and a host of other benefits with absolute minimal memory and performance overhead.