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