[cap-talk] Argument for capabilities as data in NLTSS

[Jonathan S. Shapiro]

On Mon, 2007-07-16 at 11:28 -0700, Jed Donnelley wrote:
> I just thought I'd briefly repeat the argument that was made
> during the early days of the NLTSS design that resulting in
> favoring capabilities as data in that system vs. capabilities
> as protected descriptors (classical capabilities).
> 

The argument contains a flaw:

> 2.  If we were going to implement a serialization
> protocol for network capabilities, then any computers
> that had access to the network would have access to
> what amounts to capabilities as data for any capabilities
> that are distributed on the network.

This seems to ignore the possibility of network layer encryption and of
mutually authenticatable nodes. Automatically bootstrapping the latter
has only recently become possible, but it clearly could have been done
by hand at the time of NLTSS. Cryptography, of course, was then well
established.

So this assumption seems transparently wrong. What am I missing here?

> 3.  Why limit processes that run under some OS on
> a network to having less access than computers that
> run on the network?  By providing less access you
> are really fooling yourself if you think that you are better
> protecting your capabilities, because those capabilities
> will still show up as data in the computers on the
> network.

It is fairly clear that we can protect supervisor memory from incursion
by applications, so there is a clear distinction to be made between raw
capabilities appearing in supervisor memory vs. raw capabilities being
accessible to user-mode code.

So this assumption also seems transparently wrong. What am I missing
here?


I suspect that the systems integration needed to sustain the design I am
contemplating probably wasn't there yet when NLTSS was being designed.
What seems transparently wrong in hindsight may not have been obvious at
the time. Jed: can you shed some light here?

shap
-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC