[cap-talk] kernel object knowledge

[Jed Donnelley]

Jonathan S. Shapiro wrote:
> On Wed, 2007-05-30 at 10:03 -0700, Charles Landau wrote:
>
>   
>> In KeyKOS, Processes store capabilities only in Nodes (for example, 
>> the key registers node). The kernel must implement Nodes, but need 
>> not implement Processes (at least, not for that reason).
>>     
>
> I was trying to restrict myself to the context of Jed's original
> question.
>
> More generally, the kernel must implement those objects that contain
> sensitive or privileged state. Capabilities are merely an example case.
>
> More precisely, these must be implemented by universally trusted code.
> It is conceivable to implement a system in which the kernel performs
> only communication operations, and the code that we would normally think
> of as a kernel is implemented by a supervisor-mode process. However,
> this is merely an implementation technique. It doesn't change the
> essential requirement.
>   

I'd like to explore the nuances of 'kernel' and 'universally trusted'.

What I mean by 'kernel' is the code that has access to real memory
with no protection.  Unconstrained memory access.

In the NLTSS system, for example, these elements qualified
as being in the 'kernel'

1.  The CPU driver.  This code managed the exchange from one
process "domain" to another - e.g. setting up memory mapping.
It also did the initial trap handling for processes (e.g. clock,
segment fault, or the one NLTSS system call - the message
system call - where it dispatched the message system).

2.  The message system.  This code handled communication between
processes.  It was generally initiated when a message system call
was done by a 'user' process.  However, this code handled both
local and remote (network) communication, so it included the 'driver'
for the network device.

3.  The disk driver.  This code set up commands to the disk to
do direct memory transfers, handled status codes, etc.  This code
could transfer data anywhere in memory, so it was part of the
kernel.

At this point perhaps I should respond to David Hopwood who says:

> I consider the term "device driver" unhelpful; it covers a vast range
> of things, many of which do not control devices (unless the term
> "device" is generalized to the extent that it would be clearer to say
> "object").
What I mean by a "device driver" is code such as above that can set
up transfers to and from unprotected memory and thus must be
trusted and I say is part of the 'kernel'.

I don't consider the 'device driver' term to cover a "vast range of things".
Is my terminology out of date in this area?  Is there a more specific
term that means what I do when I refer to a "device driver"?


The above three elements were the only parts of the NLTSS code
that I considered part of the 'kernel' and also the only parts that
I considered 'universally trusted'.


Now let me consider a couple other parts of the NLTSS system to
see what category they fit into:

4.  The Process Server was the only user level process that was
trusted to communicate with the CPU driver.  The Process
Server could add new processes to the run queue, determine
their time slice, the initial and restart values of their registers
and memory, etc.  The Process Server reported process
status to other process controlling processes.  It could
create and destroy processes, etc.

The Process Server could not effect the memory resident
processes - e.g. itself and the File Server:

5.  The File Server was the only user level process that was
trusted to communicate with the disk driver.  It communicated
with other user processes (e.g. for read, write, create,
and destroy requests) and with the disk driver to read
and write data to disk - generally as an intermediary for
I/O operations requested from other processes.

I would say that the NLTSS File Server and Process server
were heavily trusted, but I would not say "universally" trusted.
E.g. the File Server did not need to trust the Process Server.
Indeed we didn't even have a Process Server during the
earliest development stages of NLTSS (processes were built
into the system load).

The Process Server trusts the File Server to read the
same data that it wrote to files.  If this were to fail then
swapping/paging would not work properly for processes
that were not memory resident (nearly all).


Now consider one last code set:

6.  The Directory Server was a process that allowed
capabilities (just blocks of data in NLTSS) to be stored
by name.  It also supported access permissions like
insert, delete, and the previously mentioned "free access".

Any user could have implemented their own "directory server"
if they wished with other semantics - perhaps trying to sell theirs
to the community.  It was useful having a high performance
Directory Server (heavily cached and memory resident) for
naming objects and we felt with the semantics (features)
that we offered, but I would certainly not consider the
main NLTSS directory server as "universally trusted".


So ...  One of the main ideas of capabilities is POLA, right?

As you can see in the above, for me 'kernel' means
essentially unconstrained access (able to read and write
anywhere in memory).  After that every code is POLA.
Where does "universally trusted" come in?

--Jed
http://www.webstart.com/jed/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20070530/c6483a9f/attachment-0001.html