Comparing IPC and capability invocation

[Hermann Härtig]

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 
communication patterns.

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 
"object" boundaries.
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 
>>mappings?
> 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.
Hm?

--hermann