Translucency counterexample

[Jonathan S. Shapiro]

I have just come up with the anticipated example where read-only
translucency would create a problem in EROS. It violates the
isInstanceOf() mechanism.  My comment may make more sense after you look
at the EROS brand mechanism in the note that I will publish very
shortly.

This particular example has an easy fix, but where there is one there
will soon be two.



Suppose I use my storage to obtain a ProcessCreator.

Ultimately, the only purpose of a ProcessCreator is to support
isInstanceOf(). Everything else that it does is pure convenience.

The important property of a ProcessCreator is that it holds one
capability that nobody else can read. This capability is used to label
all processes created by this process creator. This is kind of like
branding a cow (which is why we call the capability the "brand" and the
slot in the process state the "brand slot"). There is no operation on a
process capability that allows brand slot to be examined or modified.
This means that a process cannot alter its brand.

Later, the process creator can check whether it created a given process.
There is a kernel service ProcessTool that implements an operation

  identify(ProcessCap,OtherCap)=>Bool

this returns true exactly if OtherCap matches the capability stored in
the brand slot of the Process that is named by ProcessCap.

This check is fairly important:

  It prevents me from handing you a process that runs one program
  and claiming that it runs another (more mechanism is needed, but
  this is the underlying means of implementation).

  ProcessCreator instances also *destroy* processes. The brand
  prevents me from using *my* ProcessCreator to destroy *your*
  process.


The problem is that the ProcessCreator was built with my storage. This
means that I can inspect it, which means that I can extract the secret
brand capability. The ability to extract the brand capability means that
I can violate the integrity of the process type system. If this
integrity is violated, the foundational chain of trust is broken because
even the *primordial* servers cannot be reliably identified.


Now in this particular case the "fix" is very simple. The function of
ProcessCreator should have been done in the storage allocator in the
first place. Separating out the ProcessCreator functionality seemed like
a good idea when it was done but probably was not in hindsight.

But the thing is: where there is one example there will turn out to be
two.


shap