l4-hurd
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A comment about changing kernels


From: Matthieu Lemerre
Subject: Re: A comment about changing kernels
Date: Sat, 29 Oct 2005 09:34:32 +0200
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Bernhard Kauer <address@hidden> writes:

> On Fri, Oct 28, 2005 at 08:03:04PM +0100, Neal H. Walfield wrote:
>> > > The problem with L4.sec is the following: It does currently not have
>> > > all the operations that we think we need (I am thinking specifically
>> > > about efficient capability copy and identification). 
>> > 
>> > Just some comments from the L4.sec perspective:
>> > 
>> > The identification via read_badge() is something which will in my
>> > opinion be part of the kernel if we do not come with a better solution
>> > to solve the multiple capability-parameters problem. Since the read_badge()
>> > operation could change, it is currently called "experimental" in the spec.
>> > 
>> > Now to copy(): I know no functional argument to introduce a copy() into
>> > L4.sec.
>> 
>> Have you considered this argument [1]?  I'd be interested in hearing
>> the reactions from the L4.sec perspective.
>
> This concluded, that simulating a copy with a central cap-server is not
> possible. You have to call the parent, to do the map for you. In the flat
> hierarchy for example this is the server who implements the user-level
> object this capability stands for.

But then the server knows how many clients it serves, and maybe we
don't want the server to know that.

One obvious solution, though, would be to put a trusted "mapper" proxy
between the server and its clients, which would be used for new
capabilities and copy of these capabilities.  But performances would
be bad if many capabilities have to be returned.

Matthieu




reply via email to

[Prev in Thread] Current Thread [Next in Thread]