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

[Valerio Bellizzomi]

On 28/12/2006, at 11.51, Jonathan S. Shapiro wrote:

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

The first thing that comes to my mind is a "seek"-like operation in the
translation logic. It would have the power to address page table entries
(like "seek" has the power to address file records or disk sectors), but
NOT the power to alter the entries.
With an operation like this one, you would be able to traverse the page
table opaquely, without reading capabilities with TAKE, it should work if
page table entries are fixed-length.
But I'm quite sure that I'm missing something..Probably capabilities must
be read in order to perform address translation ?

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