
From L3 to seL4: What Have We Learnt in 20 Years of L4 Microkernels? [pdf] - pjscott
http://www.nicta.com.au/pub?doc=6930
======
Rusky
Microkernels are a nice step toward security, but they're a concept ahead of
current hardware design and they don't really bring the flexibility typically
promised.

Services (virtual memory/swapping, file systems, the network stack, etc.) in
microkernel systems typically can't be modified or replaced by applications
any more than in monolithic kernels, which is probably party of why
microkernels have stayed in the realm of embedded systems, etc. where you have
control over the whole system.

Exokernels bring the flexibility that microkernels don't, by moving the
security boundary down the stack. Instead of moving services into trusted
user-level processes, they manage protection at the level of hardware
resources rather than services. This enables those services to be in untrusted
shared libraries that can be securely modified or bypassed on a per-
application basis.

Thus, instead of the lingering "eh, it's a little slower but we can ignore
that," exokernels provide much better opportunities for optimization and tend
to be much faster. For example, a database could choose to discard and
regenerate index pages rather than swap them out to disk and back; a file copy
program could issue large, asynchronous reads and writes of all the copied
files at once; a web server could use its knowledge of HTTP to merge packets,
or co-locate files from web pages to improve disk seek time.

Further, exokernels and microkernels are not mutually exclusive; they are
rather orthogonal concepts (you could move an exokernel's drivers into user
space processes if you wanted). If we had hardware that were more conducive to
a microkernel design, for example with direct process switching rather than
going through the kernel (32-bit x86 did this with task gates, but they
weren't used much and were abandoned with 64-bit), this would probably be the
optimal design, rather than a purist microkernel approach. Incidentally, the
in-development Mill CPU design does this very efficiently, as well as a few
other things that are good for both micro and exo-kernels.

~~~
nhaehnle
Exokernels tend to be a good idea for quite a number of things. In fact, all
modern desktop systems use what is essentially an exokernel design in their
graphics driver stack:

Rather than implementing OpenGL (or Direct3D or whatever) in the kernel, the
kernel drivers provide an interface that allows user space to submit hardware-
dependent command lists for the GPU.

OpenGL is then implemented as a very thin layer that loads a hardware-
dependent user space library. It is this hardware-dependent library that
contains the vast majority of the OpenGL implementation, including the shader
compilers and everything else that is needed to build the hardware-dependent
command list that is ultimately submitted to the kernel.

~~~
anon4
And you've just described the current state of Open-Source video drivers in
Linux.

~~~
e12e
I believe both Windows NT and OS X do it this way, in addition to closed-
source video drivers for Linux and Android? Not certain, and I won't speculate
about iOS.

~~~
gsnedders
Windows (NT) does since Vista. But I thought OS X still had all of it in
kernel-space? Not sure though.

~~~
kijiki
All the major OSes evolved through different paths, but eventually ended up
with very similar schemes.

Windows (ignoring the 9x series): In NT 3.x, GDI was just a thin DLL that
RPC'd over to CSRSS.EXE. CSRSS did the actual drawing directly from userspace.
As recently as XP (I haven't checked later) CSRSS still has an elevated IOPL,
which meant that despite being a userspace process, VMware had to use binary
translation on it, instead of direct execution. In NT4/XP, GDI (and some other
stuff) moved into win32k.sys. Userspace would essentially do a syscall, and
the kernel would talk to the video card. For 3D graphics, the model is that
userspace apps load a video-card specific library to generate command buffers
for the video card. When the app wants to execute a command buffer, it uses a
syscall; the kernel verifies that the commands are safe, and submits it to the
hardware. In Vista and later, a path similar to the 3D path is used for all
drawing, only the drawing is done on an app-specific offscreen surface.
Another userspace process generates command buffers to composite those
offscreen buffers together to generate what you see on the screen.

Linux/X11: In the dark ages, it was very similar to NT 3.x (X came first, I
just ended up writing in this order). Applications used xlib to generate X
protocol messages which were sent via a unix domain socket, or a TCP socket to
the X server. The X server then, from userspace, programmed the video card.
This had the same IOPL implications for the X server as CSRSS.EXE. When 3D
acceleration was added, it worked very similarly to 3D in NT4/XP. Finally,
with compositing and now Wayland, the model is similar to Vista+.

OSX: In NextStep/early OSX, applications drew (software only) into shared
memory chunks. A userspace compositor process did software compositing from
those shared memory chunks into the video card's VRAM. With middle OSX (can't
recall exact versions here), the compositor process started to upload dirty
regions from the shared memory chunks into offscreen VRAM surfaces, and then
programmed the video card to composite them together. Finally, modern OSX
works similar to modern Linux and Vista+.

I just wrote them up in this order arbitrarily. X did drawing via RPC to a
user-space process long before NT and NextStep existed. NextStep did
compositing _long_ before the other two. Ironically, given the flamewars and
marketing of the 90's, Linux/X was exactly as "microkerneley" as NT3.x and
NextStep, and more so then NT4. And they all evolved towards very similar
architectures.

------
greenyoda
This article is a PDF document. Here's the abstract:

 _The L4 microkernel has undergone 20 years of use and evolution. It has an
active user and developer community, and there are commercial versions which
are deployed on a large scale and in safety-critical systems. In this paper we
examine the lessons learnt in those 20 years about microkernel design and
implementation. We revisit the L4 design papers, and examine the evolution of
design and implementation from the original L4 to the latest generation of L4
kernels, especially seL4, which has pushed the L4 model furthest and was the
first OS kernel to undergo a complete formal verification of its
implementation as well as a sound analysis of worst-case execution times. We
demonstrate that while much has changed, the fundamental principles of
minimality and high IPC performance remain the main drivers of design and
implementation decisions._

------
kbenson
Oh, the conundrum that is the very technical HN story. Do I dive in and devote
the time to learn whether this is paper is as interesting as it seems on the
surface, or do I wait for some explanatory posts or even a TL;DR summary to
help me decide?

Edit: The paper helpfully provides much of this itself, with boxed section
footers with the change from then to now in how that component is handled. It
makes for an interesting way to skim and zero in on sections you may find of
interest.

e.g. _4.2 Lazy scheduling_ ends with *Replaced: Lazy scheduling by Benno
scheduling"

~~~
panzi
The way to read papers: Read the abstract, if still interested read the
conclusion, if still interested read the rest.

~~~
twic
While working as a cell biologist, i followed a different approach: ignore the
abstract, look at the figures, if still interested skim the materials and
methods, and if still interested, read the rest.

The rationale for this is that the most interesting thing is what the authors
have discovered, but it's only interesting if they've used sensible and
relevant methods, and what is very unlikely to be interesting is the authors'
attempt to convince you that the result is stronger and more important than it
is.

~~~
panzi
Yeah, "my" approach[1] is probably best suited for computer science papers.

[1] It's not really mine, it's what I was told at university.

------
jacobolus
The OOTB/Mill people are apparently working on porting L4/Linux to their
architecture:
[http://millcomputing.com/topic/security/#post-802](http://millcomputing.com/topic/security/#post-802)

Their machine-supported security features will be very interesting to see
realized.

------
harry8
"For a successful technology, reality must take precedence over public
relations, for Nature cannot be fooled." \--Richard Feynman

All of us need to learn this, re-learn it, revisit it, internalise it, live it
and breathe it every day. I'm sure I could do better at attaining such an
ideal. So too can these gentlemen.

