Comparing IPC and capability invocation

[Jonathan S. Shapiro]

On Sun, 2003-12-07 at 10:10, Hermann Härtig wrote:
> shap: [I apologize in advance for both the length and the depth of this 
> note.]
> so do I
> 
> In Dresden, a group of us is discussing related issues since a while ...
> 
> I am convinced since a long time
> * that communication should *not* be addressed to threads, or - in other 
> words - a service's thread structure should be completely transparent to 
> clients.

We have certainly found this helpful in EROS. If nothing else, it lets
us save a system image, replace the kernel, and restart it without
logical interruption of execution. I'm not sure how relevant my example
is to L4, but there are many reasons why the implementation details of
kernel structures should be opaque.

As a middle ground, I would qualify that by saying: opaque with the
possible exception that pagers for these structures (if any) will
certainly need to know about them.

> * that all resources exported by the kernel (address spaces, threads, 
> memory, interrupt lines, ...) should have a local name (now in L4, only 
> memory has local names -> virtual addresses)...

I believe that we are in agreement, but I want to confirm that I have
understood you correctly. I believe you mean:

  all resources exported by the kernel (address spaces, threads, memory,
  interrupt lines, ...) should be referenced by processes using names
  that are local to the process.

The distinction I am trying to be clear about is this:

Real resources intrinsically have global names. Physical pages, for
example, have names that are dictated by the hardware wiring of the
memory subsystem. Every thread similarly has a unique global identity.

I think what we are both saying is that such global names for kernel
resources should not be revealed outside the kernel. If so, we are in
agreement.

Here again I would make a potential exception for pagers. At certain
very low levels of the system, there is application code that can and
should know something about the mapping from local names to global names
within its own context.

>  All types of resources 
> provided by the micro kernel can be transfered from a "pager" to a 
> "client" via IPC just like page faults are handled now in L4 (mapping 
> and flushing). Then, all resources are initially owned by sigma0 and 
> L4's elegant pager hierarchies can be easily extended to all (types of) 
> resources.

If I understand you correctly, then I agree, but it is important (at
least for the moment) to speak very precisely about what is meant by the
statement you have made.

The item transferred is not the resource. The resource exists and has
unique identity. The item transferred is the (protected) global name of
the resource, and the result of the transfer is the establishment in the
recipient context of a new name, local to the recipient, that maps to
this resource.

Is this what you meant?

>  "Mapping data bases" are then needed for all types of 
> resources  as well.

The mapping model is the single biggest difference between EROS and L4.
I would like to defer consideration of extending the mapping database
until we agree (or agree to disagree) whether the current L4 mapping
model is really the one that we ultimately want. I see definite
strengths in the current L4 model, but I also see definite weaknesses.

> (I see no benefit though of a "unified capability space". Memory 
> "descriptors" are PTEs.)

It is a question of naming. Let me set aside memory descriptors, as this
is going to need to be a subject for careful discussion.

The question is: given that there exist local names for all resources,
should there be a common invocation mechanism that is used to invoke the
interfaces on these resources?

If so, then we want a logically unified capability space, because we
want a logically unified notion of local name. On most platforms, the
PTE is not an effective data structure for this purpose.

> (I see no benefit though of restricting communication to "calls on 
> objects". User-level SW of course can restrict communication to such 
> patterns, but why should a micro-kernel enforce such restriction? 

It is not a restriction. It is a generalization. The behavior of L4 with
local names is a strict subset of the behavior of EROS start
capabilities. See below in my comments about compatibility.

> Dresden's version of an IDL compiler is designed to support arbitrary 
> message patterns. User-land "objects" should remain a user-land issue.)

I agree that user-land objects should largely remain a user-land issue.
The issue is that if the user-land server has no efficient means to
implement a protected name for a user-land object, significant power and
performance are lost.

> The question now is: how does a receiver identify the sender?
> J.S. says: no need to identify since there are capabilities. I disagree 
> here: relying just on capabilities leads to much-too-fine grained 
> clustering of protection units.

Based on 30 years of experience with KeyKOS and EROS, I would say that
the evidence does not entirely agree with you.

However, let us be careful what we mean: I am not saying that
unforgeable sender identity is bad (though I do believe this). I am
saying that it is insufficient. You have not yet proposed a response to
my question about how a single sender can simultaneously hold both a
logically read-only descriptor and a logically read-write descriptor if
there is no way for the server to efficiently differentiate the type of
the descriptor that was invoked.

>  From my point of view, we need to enable protection units to securely 
> find out from which clients messages came in, or - in other words - to 
> serve clients with fairly different rights.

There are system designs for which this is true. There are also system
designs for which it is NOT true. I disagree with this statement on
three grounds:

  1. It favors a particular set of policies -- those based on invoker
     identity -- in the microkernel. It strongly disfavors pure
     capability policies.

  2. It favors an access control model that has been repeatedly
     demonstrated in formal analysis to be unsafe.

  3. It assumes that clients with "fairly different rights" cannot
     be effectively served through any means other than a unique
     client identity. Based on our experience in EROS/KeyKOS this
     is clearly mistaken.

I will not (and do not) argue that the existing L4 work that builds on
sender identity should be discarded. I believe that it is founded on a
known unsafe protection model, and I would encourage giving some
attention to whether my belief might be correct, but I'm prepared to
believe that I may be mistaken, and I believe that there exist systems
we wish to build on top of the microkernel that require this function in
order to execute efficiently.

However, I DO argue that a good microkernel should not strongly disfavor
a protection model that is known to be sound in favor of one that is
known to be unsound.

Thus: I would (provisionally) prefer a microkernel in which there is an
'extra word' in the "recipient descriptor" (the replacement for
thread-id), and in which the unique sender identity is set by the thread
pager (which I assume is trusted).

Given such a design, all of the current L4 servers can continue to
execute unmodified by simply ignoring the extra word, and all of the
current EROS servers can execute unmodified by ignoring the unique
sender ID. In EROS, for reasons of protection, our thread pager would
deliberately zero this field.


I will defer comment on the ports issue until I have time to think about
it some more.


shap