Bernhard Kauer <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
