L4, High Assurance, and Protection

Gernot Heiser gernot at cse.unsw.edu.au
Tue Jan 6 14:34:54 CET 2004

>>>>> On Tue, 6 Jan 2004 13:15:50 +0100, "Volkmar Uhlig" <volkmar at ira.uka.de> said:
>> -----Original Message-----
>> From: Hermann Härtig [mailto:haertig at os.inf.tu-dresden.de] 
>> Sent: Tuesday, January 06, 2004 11:07 AM
>> BTW, the perception that Jochen Liedtke considered speed to dominate 
>> everything else (see some earlier email) is simply rubbish. 
>> Jonathan's statement "that performance cannot be used to justify 
>> fundamental insecurity" could as well originate from Jochen Liedtke.

VU> The hitserver is an example where this perception is not rubbish (as you phrased it).

VU> The point I tried to make is that if you want generality of the
VU> kernel you have to look at a wide area of applications.  As I
VU> stated in previous emails, I'm aware of the insufficiencies of the
VU> security model in L4 and I believe that this is well taken care of
VU> by many people looking at.  The same is not true for the
VU> performance aspects and my feeling is that "all these important
VU> security features" are used to fatten and to slow the kernel
VU> unreasonably.

Hmm, Volkmar, I have to agree with Hermann. One of the core tenets of
OS designers should be that performance cannot buy security, and an OS
without security is worthless. And security isn't optional.

To use your wristwatch example: Someone who really doesn't want
security is going to use a microcontroller without MMU, and hence not
run L4. If you have an MMU, you worry (almost by definition) about
security. And the wristwatch examples are on the way out: just about
any embedded system under development now or in the near future (and
that is an important part of the L4 market) is being networked, and
hence must worry about security.

There are much stronger drivers of kernel-bloat than security at the
moment. Multiprocessor scalability (up _and_ down) for example.

VU> Since you referred to Jochen here a quote from "Improving IPC by kernel design":
VU> 	"IPC performance is the Master.  Anything which may lead to higher IPC performance has to be discussed. In case of doubt, decisions in favor of IPC have to be taken. But the performance and security qualities of other components must not be seriously impacted."

Jochen said other things that have been proven wrong in the
meantime. For example "a microkernel must be unportable", as you guys
have shown ;-)

The above quoted statement must be seen in the context of improving
IPC performance by more than an order of magnitude over predecessors,
by taking a radical approach. An OOM cannot be hidden at application
level. Howver, 10% performance difference at the microkernel API will
be difficult to detect at the application level (you remember the work
on small address spaces?)

And I definitely agree with Jon: It's end-to-end performance that
counts. Microbenchmarks are great for analysis, but worthless for

VU> So far there is no sound model proposed which doesn't add
VU> significant overhead and which has the same elegance as L4 today.

Clans-and-chiefs was "elegant" in a way, but it sucked so much that
no-one used it. And some of the things in the X.2 API are much less
elegant than previous versions (like the dreaded non-delegatable root
task). Again, I cannot help agreeing with Jon (apologies for the
misquote): if the API forces complexity on the system built on top,
then the API is broken. (Which is just another variant of the
end-to-end argument.)

Gernot Heiser                        School of Computer Sci. & Engin.
Professor of Operating Systems       The University of NSW
Phone: +61 2 9385 5156               UNSW SYDNEY NSW 2052, Australia
Fax:   +61 2 9385 7942               http://www.cse.unsw.edu.au/~gernot

More information about the l4-hackers mailing list