Comparing IPC and capability invocation
haertig at os.inf.tu-dresden.de
Fri Dec 12 18:33:20 CET 2003
Jonathan S. Shapiro wrote:
> On Mon, 2003-12-08 at 12:31, Hermann Härtig wrote:
> ALL communications are invocations on objects. The only questions that
This "credo" clarifies the fundamental difference.
In L4 thinking, "objects" is a user-level abstraction. L4 supports a
fixed minimal set of resources provided by the kernel:
task(addresspace), thread, pages, ... . Mappings correspond to such
kernel resources. Everything else is "second class", i.e. built on top
of it using IPC. Then, allowing just "object"-invocation-like
IPC(synchronous calls) is a restriction compared to arbitrary
In Eros, everything is and must be "invocations on objects" regardless
of whether they are provided by the kernel or in user-land to the extent
that user-level objects are represented by some kernel entity. Then,
allowing invocation on kernel-objects only is a restriction.
Here, it is my strong belief that L4 (with all its problems that still
need to be resolved) has it right! "Objects" are user-land business to
the extend that clever compilers may decide to optimize away certain
I have to emphasize the *belief* in the previous paragraph.
Other differences fall out of that fundamental difference:
> L4 imposes the restriction that the only invocable object type is
> "process" (or in some cases thread).
"It is a generalization, not a restriction."
> L4 does *not* (today) provide means to allow a server to extend the
> object name space.
But is allows servers to build arbitrary name spaces on top of L4. It is
not kernel business to provide a name space for user-land objects. Name
spaces are often defined by user-level standards (e.g., file ids).
> 1. The invoker should not know the server identity. That should
> be known only to the file object.
> 2. It is difficult to transparently virtualize objects when their
> invocation patterns are different.
We need means to transparently intercept IPC (we have several different
proposals for that in the L4 community). And that is all that is needed.
Arbitrary invocation patterns can be built and virtualized in user-land
if IPC is really fast.
> Descriptors, which *can* be used as a foundation for certain kinds of
> security, suddenly become extremely inefficient because they cannot be
> passed without consulting a third party.
Caching solves that problem. I have no problem with "descriptors". But
descriptors in a micro kernel should be descriptors (mappings) on kernel
resources, not "objects". The kernel can do nothing to protect "objects"
since they are in the hands and at the mercy of user-land. Therefore, no
need to have any notion of "objects" in the kernel.
Note the "certain kinds of security" for your tutorial in Dresden.
> (process-id, server-defined-bits)
Despite the fundamental difference, the implementation ideas seem
somehow similar. The sender id mechanism in the generalized mapping
discussions can (at first view) be used to build server-defined-bits on
top of it (see my previous email). Simply, let the server act as pager
providing for the clients. But sender ids allow many more schemes.
>>In our thinking, the unit of protection is an address space. Why need
>>anything else but unforgable sender ids plus control of IPC via send
> Because these are architecturally insufficient to implement an
> efficient, secure, object-based operating system.
I do not buy this. Here is the fundamental difference again.
> This is a good start, but our experience is that hierarchical
> restrictions of this form do not map well to the real problem space.
More information about the l4-hackers