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 tomy 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