IPC/Capabilities Overview

Jonathan S. Shapiro shap at eros-os.org
Thu Jan 1 01:37:10 CET 2004


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





More information about the l4-hackers mailing list