Comparing IPC and capability invocation

[Hermann Härtig]

Jonathan S. Shapiro wrote:

>>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.
...
> 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.
Sure. Pagers are not clients.


>   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.
That is what I tried to say.

> 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?
Yes, thanks for the clarification!

>>(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.
This I do not understand (-> note for your tutorial in Dresden).

>>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.
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?

>>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.
My intuition is otherwise. I need to learn much more on EROS. 
Unfortunately at this point, my time is too limited already to follow 
the current discussion carefully. Hope,  your tutorial in Dresden will 
help (I managed to get rid of almost all obligations for that week ...).

> 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 are right; we know that.

>                             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.
Two answers:
1) This is simple if we - as we discuss in Dresden - associate ids 
("Principal Id") with a send mapping (what you call a descriptor). The 
kernel enforces that a message contains the "Principle ID" as the first 
part of a message (instead of a sender id based on threads ids).  Then 
you can associate one id with the "logically read-only descriptor" and 
another with the "logically read-write descriptor".
2) The scenario is not interesting. If a single sender holds "both a 
logically read-only descriptor and a logically read-write descriptor" 
there is no way to stop a sender to use the descriptor granting more 
rights. The descriptor cannot base anything on the knowledge which of 
the two descriptors has been used.


>> 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:
 > ...
This should be part of your tutorial in Dresden.


> 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).
The "extra word" is the proposed "Principal Id" in the send mapping. The 
pager is trusted with regard to the id space given to it. For example, 
if a pager has send mappings with Principal Id "2" it can map only 
forward mappings that begin with "2". Especially it can restrict the 
name space of the next pager "25".

Attention, Jonathan! You are currently exposed to several different 
lines of ideas on how to overcome the current limitations of L4. This 
must be very confusing ...

--hermann