IPC/Capabilities Overview

Jonathan S. Shapiro shap at eros-os.org
Mon Jan 5 16:16:19 CET 2004


On Thu, 2004-01-01 at 18:09, Volkmar Uhlig wrote:
> Similar to Rudy I try to answer multiple mails at once.  (Sorry for the
> long post!!!)
> 
> First a general statement.  It appears to me that goals are very
> different.  As Rudy pointed out one of the main goals of L4 (at least
> pursued in Karlsruhe) is to have a universal and high performance uK.
> Universal here means that it is applicable to any domain.

Actually, this is the goal that I am hoping to achieve. Today, L4 seems
a very inefficient platform for constructing a protected, object-based
operating system.

I won't suggest (and I don't believe) that EROS is the ultimate example
of such a system, but perhaps you will consider the following as a
challenge question:


  Assertion [yours]: L4 is a universal uK.

  Test: implement the semantics of EROS correctly and with reasonable
  efficiency on top of L4.

  Hint: Today, you cannot, because L4 does not provide adequately
  protected IPC.

I can say confidently that neither Jochen nor I could figure out how to
do it. The EROS reliance on protected descriptors is too deeply embedded
and too critical to performance. You could do it without all of the EROS
kernel object types -- Leendert and I figured that part out. What we
can't figure out is how to do it without (a) protected thread-ids, and
(b) that in-kernel word per descriptor.

> That also
> answers Rudy's question who is going to use a microkernel without a
> security model--anybody who does not require a security model.  And that
> may be your wrist watch, cell phone, or a medical appliance.

The wrist watch I might believe. Cell phones and medical appliances are
both areas that are suffering badly from the absence of protection.
Recent attacks on phones have made this pretty clear. In medical
appliances, I'm not aware of security issues yet, but I'm definitely
aware of *reliability* issues, and the underlying requirements for truly
high-reliability systems are very very similar to the underlying
requirements for secure systems. They begin with protection.

Perhaps there should be two specializations of the kernel API: one where
protection must be supported and one where it is not needed. I am
prepared to believe that unprotected systems should not pay the cost of
protection. My problem is that protected systems similarly should not
pay the cost of non-protection.

> We also have to agree on what system you and I have in mind and from
> that we can derive the overall costs.  To me it seems you are implying a
> system design and claim that L4's lack of certain features makes it
> perform as good/bad or worse.

Yes, in part, I am. But if L4 is indeed a universal microkernel -- or
even a reasonable approximation to a universal microkernel -- then it
should be able to efficiently support any particular system.

My claim is that L4 is missing one essential abstraction in the IPC
mechanism: protection.

> Now the question changes
> to how efficiently can we implement it in user land compared to the
> in-kernel version.

That is one important question. The other important question is: if we
implement it in user land, can we implement it with correct protection.

> Performance is
> still one of the main reasons why monolithic kernels are preferred over
> uKs.

Based on experience, I am not convinced of this. I have been deeply
involved in three very large scale decision processes about uK
acquisitions and transitions. In each case, the outcome went *against*
the uK for good reasons. As far as I remember, IPC performance was
raised in the discussoins only as a curiosity. It never once played a
significant role in the decisions.

The problem, in each case, was that the systems (including their
microkernels) had not been effectively engineered in an end to end way.
We saw evidence in each case that *overall* performance was terrible,
but this was usually NOT due to IPC -- IPC frequency was actually quite
low. It was the result of bad systemic design (certainly including the
microkernel).

There are two possible conclusions that can be drawn from this:

  1. Microkernels need to be faster than they used to be.
  2. Microkernels and the systems on top of them need to be
     engineered with a better view of end to end design.

Up to a point, I think that (1) is correct. Past that point, (2) becomes
dominant. This is why EROS uses an object-based rather than a
process-based invocation system, and it is why we are willing to pay the
cost of protection in the invocation mechanism. It remains to be seen
whether we got it right, but recent performance numbers for our window
system and our network system look very very promising.

In actual fact, I have only once seen a figure that has broken down for
any production microkernel the total time spent in the kernel (KeyKOS:
40%). That figure is comparable to monolithic kernels. The KeyKOS
implementation was definitely too slow, and in that generation it was
pretty much a monolithic kernel.


shap





More information about the l4-hackers mailing list