[cap-talk] kernel object knowledge

[David Hopwood]

Jed Donnelley wrote:
[...]
> 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)?

There is an important technical distinction between the "kernel"
and "globally trusted code".

In common usage, the kernel is a part of the system that is
subject to weaker protection rules than non-kernel code. This
may be because it is written in a different language that is
not able to enforce language-based safety properties, or
because it is running with different hardware-enforced memory
and I/O permissions.

Typically, the globally trusted code in a system includes all
of the kernel code. However, in any nontrivial system it is very
likely that there is also some globally trusted code outside
the kernel.

It is preferable, all else being equal, to put any given component
outside the kernel (even if it must still be in the global TCB),
for the following reasons:

 - memory safety, and improved fault isolation;
 - in some cases, an easier programming model (although it would
   be possible to make the kernel programming model much simpler
   than it is in current monolithic OSes);
 - simpler use of debugging tools.

All else may not be equal, though -- moving code outside the kernel
may complicate the design, and in some cases it may even increase
the total size of the global TCB.

[...]
> 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.

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").

A "printer driver" is normally just a filter that converts an image
or document layout format to the format expected by the printer.
It may also need to communicate with the printer to perform diagnostic
and maintenance functions. It doesn't need to be trusted except by
subjects that are relying on correct printer output.

The driver that may need to be globally trusted is the port driver
(USB, parallel, etc.) Given an IOMMU or use of language-based
security, even that may not be necessary: the least privilege
for a port driver only allows it to interfere with use of that
type of port.

-- 
David Hopwood <david.hopwood at industrial-designers.co.uk>