[cap-talk] Another "core" principle - Brinkmann

[Jonathan S. Shapiro]

On Thu, 2006-12-28 at 01:32 +0100, Valerio Bellizzomi wrote:
> On 27/12/2006, at 1.47, Jonathan S. Shapiro wrote:
> 
> >On Sat, 2006-12-23 at 14:38 +0100, Marcus Brinkmann wrote:
> >> * My personal model of capabilities is stricter than yours.  For
> >>   example, I only allow capability delegation through authorized
> >>   channels, which exists in form of capabilities of course.  So,
> >>   whenever a capability is communicated from A to B, I need a
> >>   capability that is used for that.  Even if you think about
> >>   capability transfer in form of copying binary blobs of data...
> >
> >But of course, binary blobs of data are only transmitted over authorized
> >channels as well.
> >
> >Let me re-introduce some terms, because some readers may not have them:
> >
> >   read  == read of data
> >   write == write of data
> >   take  == read of capability
> >   grant == write of capability
> 
> 
> How can we think about diminish-take ?

The four access rights that I identified above are the "classic" ones
from the early capability information flow literature.

Diminish-Take is an additional access right that is similar to take. I
didn't introduce it here because I didn't want to confuse the discussion
about the flaws of the early capability literature.

Based on a number of conversations, it is not necessary to add
diminish-take to the fundamental access rights in order to achieve all
of the things that we have been discussing here. The benefit of
diminish-take is that it provides support for copy-on-write behavior
that cannot otherwise be modeled without appealing to privileged code.


I should also add that the four "classic" rights above are inadequate to
account for protection in capability operating systems. The example that
makes this clear is page tables. For simplicity of explanation, I will
assume here a *single* level page table scheme.

A page table is an OS-protected, fixed-length vector of page table
entries. Each page table entry is in fact a capability: it names a page
and conveys permissions of access for that page. Let us now imagine that
we will introduce a "page table capability" allowing the holder to
insert page capabilities (or NIL) into the slots of the page table. Up
to this point, the behavior of the page table capability can be
described using the take/grant rights.

Now, however, imagine that we want to create a process using this
address space. We intend that this process should be able to access the
data in the space, but we do NOT intend that it should be able to alter
the contents of the page table.

At this point something very strange is happening, because in order to
account for address translation our process must be able to traverse the
page table, and in doing so the translation logic needs to perform TAKE
operations in order to read the page table. This is true even though the
process itself has no authority to perform such TAKE operations.

My belief is that some form of fundamental access right describing a
right of opaque traversal must be introduced to account for this. I have
fumbled with such a right several times, and I have never managed to
build a completely satisfactory model for it.


shap


-- 
Jonathan S. Shapiro, Ph.D.
Managing Director
The EROS Group, LLC
+1 443 927 1719 x5100