[cap-talk] kernel object knowledge

[Peter Amstutz]

On Tue, May 29, 2007 at 10:26:24AM -0700, Jed Donnelley wrote:

> >The kernel doesn't need to understand the semantics for either ACLs or
> >capabilities.  The kernel could simply be the trusted forwarder.  In an
> >ACL system, the kernel could forward to the handler the user's ACL entry
> >for the resource and let the handler figure out what to do.  In a
> >capability system, the interpretation of the bits in the capability can
> >be left to the object it references.  So, for example, bit 3 in the
> >capability could be interpreted as RO for a file and something
> >completely different for a start key.
> 
> When you say the kernel doesn't need to understand the
> semantics of capabilities - that was certainly true in
> NLTSS.  However, in capability as descriptor systems
> I believe the kernel does need to understand and indeed
> manage the format of capabilities - at least to the
> extent of interpreting the "invoke" and "reply"
> mechanisms and storing the capabilities in c-lists.
> Are we on the same page there?
> 
> I included so much detail in the above partly because I
> thought it might interest Peter Amstutz who started this
> thread.

I appreciate the detail, it is interesting.  Is NLTSS basically an 
capability extension of a classic message-passing microkernel, or are 
there other notable OS design differences that shake out of using 
capabilities at this level?

One aspect that may be lost in the discussion of whether the "kernel" 
understands the underlying capability model is that it is useful for the 
capability descriptor itself have a uniform model -- if I have a 
capability for an object, want to know if I can call certain methods or 
not.  I also want to be able to store the capability descriptor 
efficiently, and to be be able to serialize the capability descriptor to 
persistent storage.  It's not helpful to me to get an object capability 
back that appears to let me write to an object but actually silently 
drops all write requests.  I'd rather than the system be able to tell me 
exactly what methods are permitted with a certain capability, and to 
give back a uniform "you can't do that" error if I do step out of 
bounds.

From an efficiency point of view (as well as the extra work of 
reflection) I'm a bit uncomfortable with the E approach, whereby you 
create a restricted capability by defining a new class and a new object 
that isn't obviously connected to the underlying object without doing 
some degree of introspection.  I like the idea of being able to point to 
a simple bitfield that tells you which methods are permitted for a given 
capability.

-- 
[   Peter Amstutz  ][ tetron at interreality.org ][ peter.amstutz at gdit.com ]
[Lead Programmer][Interreality Project][Virtual Reality for the Internet]
[ VOS: Next Generation Internet Communication][ http://interreality.org ]
[ http://interreality.org/~tetron ][ pgpkey:  pgpkeys.mit.edu  18C21DF7 ]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://www.eros-os.org/pipermail/cap-talk/attachments/20070605/3198eefc/attachment.bin