[cap-talk] kernel object knowledge

[Jed Donnelley]

At 09:55 PM 5/28/2007, Karp, Alan H wrote:
>Norman Hardy wrote:
>
> > At this level of objects there are many other concepts of mutability
> > to contend with; the page, segment and directory each have their own.
> > 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.
> > Here is a failed attempt: http://cap-lore.com/CapTheory/Confine/
> > sensoryGate.html
>
>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)?

I'd be interested to hear how others feel about this topic.
To hear how it showed up in other systems.  I know how this
trade-off showed up in detail in some of the systems I've
worked on like RATS and NLTSS.  I think the NLTSS case is
the simplest and would best serve to illustrate the point
I'm getting at, so let me describe the idea there:

(ref.: http://en.wikipedia.org/wiki/NLTSS )

Consider an "NLTSS" system with only a processor with memory
and some disks - as most of our systems had.  In that case
there must be drivers to permit access to the disk and
there must be some sort of hardware multiplexing of the
processor(s) - what we referred to as the processor
driver (responsible for switching between active processes,
handling faults, adding and removing active processes,
etc.).

With such a structure the server process for the process
server must be made available as part of the system boot
mechanism.  The process server could create an init
process to initialize the file server and any other
needed base server processes.  The process server and
file server and all other server processes can be treated
just like any other "user" level process, EXCEPT
that the device drivers must trust some of those user
level processes (also the process server must keep
them resident).  In particular the processor driver
must trust the process server and the disk driver must
trust the file server.

It is the trust that the device drivers have in
the process and file servers that really make them
a trusted part of the system (kernel?).  Other
than that they are ordinary user processes.

Other servers may have similar relationships of trust with
other processes (e.g. most trust the file and process
servers).  The directory server, for example, uses
the file server as storage for directories (remember,
NLTSS was a capabilities as data system.  If not,
the directory server would presumably store capabilities
in it's c-list or in that of other processes).

So ... in terms of the above (as an example perhaps),
I don't believe the 'core' (kernel) needs to understand
'application' level resources except to the extent
that the drivers need to understand the devices that
they are driving (the process server needs to know how
to exchange between domains described by process headers,
the file server needs to understand how to issue reads
and writes to disk, etc.).

With something like a printer server (as another example),
there would still be a device driver that would have to
be trusted to some extent and the printer driver would
trust the printer server.  Other than that a printer
server would be an ordinary process.

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.

I'd be interested to hear about this trade-off in
other systems - e.g. EROS, KeyKOS, or perhaps Mach
if anybody can represent Mach.

--Jed  http://www.webstart.com/jed-signature.html