[cap-talk] kernel object knowledge

[Karp, Alan H]

Jed wrote:

> > > Norm Hardy wrote:
> > > Some capability systems have a bit presumably devoted to RO and
its
> > > generalization within each capability.
> > > We could not find a semantics for this bit in the case of a start
key.

> > Alan Karp wrote:
> >In Client Utility, we did not want the core (aka kernel) to need to
> >understand the semantics of application level resources, 
> such as files
> >and directories.
> 
> The statement above struck me enough that I thought I would focus a
> message on it.  Two things struck me about it:
> 
> 1.  What does it mean?, and
> 
> 2.  What are the consequence of pursuing it?
> 
> I believe the 'kernel' (some globally trusted code) in any capability
> system must implement (be trusted with) communication.  That is with
> moving data and capabilities from one active entity to another.
> 
> Any capability system worthy of the name must include an extension
> mechanism capable that can implement what we have referred to as
> invisible membranes - able to "membrane" or proxy any other 
> capability,
> including presumably any sort of 'kernel' known or supported
> capability.
> 
> If the above is the case then it would seem that no objects in
> capability systems needs to be implemented (known about) by the
> kernel.
> 
> Still, perhaps there is a bootstrapping problem?  Do some
> objects (e.g. those for active entities like processes) need
> to be implemented by (known about, supported by) the 'kernel'
> (globally trusted code)?
> 
All operating systems treat certain kind of things, most commonly the
file system, as things that it understands.  For example, when you say
"open w foo" in Unix, the kernel verifies that you have write permission
on file foo.  That means that the kernel must know the meaning of "open"
and "w".  It also means that the kernel must be changed if you want to
introduce a new kind of access right, say "append".   Norm's remark that
some capability systems have bits related to specific permissions and
that he couldn't always find meaningful semantics for them means that
issue is not limited to ACL systems.  Note that Norm was not talking
about an object capability system, in which there is only the object
reference, but one in which there are extra control bits in the
capability.

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.
> 
> Isn't there a similar situation that occurs in any
> capability system?  As soon as you accept that all
> capabilities need to be able to be emulated by the
> extension mechanism, then it seems to me natural
> to actually implement all object service through
> 'ordinary' user level processes - except perhaps
> for performance reasons.
> 
Yes.  That's the point I was trying to make.

________________________
Alan Karp
Principal Scientist
Virus Safe Computing Initiative
Hewlett-Packard Laboratories
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-7029
https://ecardfile.com/id/Alan_Karp
http://www.hpl.hp.com/personal/Alan_Karp