I have already responded to the substance of Rudy's note, so just a few brief points here.
On Wed, 2003-12-31 at 11:39, Rudy Koot wrote:
This goes in against their believe that "A computers get faster memory acess get relativly slower, therefore memory access should be avoided during IPC".
Based on history of processor architecture over the last 30 years, this belief is very well motivated. The problem is likely to get worse, not better.
b) For some types of systems (capability systems), disclosure of the sender id is an absolute violation of design requirements, so any microkernel that relies exclusively on server-side security checks based on sender-id is not a universal microkernel.
I never realised this, and I still don't see why this a design requirement, but if there is one this would again be a major argument in favor of capabilities. Could you give me an example of when not reveiling sender-id is useful?
I find this question very puzzling, mainly because the assumption set behind it is so different from my own.
In a capability system, the *only* question that the server can justifiably ask is "what capability was invoked?" It is an ERROR for the server to consider any other factor in making decisions. Therefore, it is an ERROR to consider the sender-id. Given this, the exposure of sender-id is a violation of the protection model, because it improperly discloses to the server information that it does not require and therefore is not entitled to have.
Hybrid: Sender can only invoke a thread descriptor that is mapped in their thread descriptor space (thread space) Server makes decisions based on either (a) a field that is encoded within the descriptor, or (b) the sender-id.
** Sender-id is software controlled by the thread manager, and can be set to zero for all threads to simulate capability behavior.
Could you explain a bit more about this thread manager. It seems to solve a problem in which the sender id does needs to be know. For example if a thread tries to write to a file, which it hasn't got write access for, it may be a system requirement that this is logged into the security log.
I am imagining a design in which "thread-id" does not correspond to thread PCB address, but rather to some global unique identifier set by the thread manager. This, of course, is very different from the current L4 design.
If the value lives in a field in the per-thread PCB, then it can be set arbitrarily by the thread manager.
If the sender-id isn't reveiled to the file server it can only log the thread-id (no not thread-id, something else but what?) to which it originally mapped the capability.
It cannot even log that, because it does not know that the original recipient is the current invoker. It can only log the identity of the capability that was used. Other mechanisms are needed to deal with tracking capability transfer.
Logging the sender-id is actually a very bad mechanism, because it assumes that the sender is implemented as a single, monolithic application. In EROS this is rarely true.
shap