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

[Jed Donnelley]

At 12:27 AM 12/29/2006, Jonathan S. Shapiro wrote:
>On Thu, 2006-12-28 at 18:19 -0800, Jed Donnelley wrote:
> > Finally, let me address this particular instance.  Firstly,
> > I confess ignorance of the specifics of the implementation that
> > the above paragraph applies to, so I may be misunderstanding
> > something.  Accepting that possibility, however:
> >
> > The above paragraph where "You (a client of the space) cannot
> > read the capability in that slot, but you can traverse it"
> > suggests a situation where a subject has a permission ("you
> > can traverse it") but cannot share it ("You ... cannot read
> > the capability).  This drops right back into mechanisms
> > that prohibit capability communication (delegation in the
> > most limited sense) - forcing something like a proxy
> > mechanism for modular extension of services in accord
> > with POLA and seeming to try to create illusions about
> > blocking communicating conspirators.
> >
> > To me any such mechanism is anathema.  I regard such mechanisms,
> > in addition to being misleading, as working against modular
> > extensions that are faithful to POLA.  I'm interested to hear
> > others (e.g. Shap) defend such a mechanism.
>
>Gladly.
>
>The mechanism that I described is the foundational mechanism of virtual
>address translation. In light of this, your position amounts to an
>assertion that hardware-based memory protection is anathema.

No it doesn't.  All it does it suggest using means (as I described
in my last note) to not mix the object-capability notion down into
the hardware layer in the way you suggested.  As long as the access
to any "pages" by the hardware is encompassed within a process
object I don't there's a problem.

>Care to reconsider? :-)

One can make virtual memory visible through a capability interface
so that it's not faithful to the base object-capability communication
paradigm (e.g. not allowing sending of received capabilities) or
you can do it so that it is.  I was simply suggesting the later.

>The "traverse" right is conceptually equivalent to having a service S
>that implements two facets A and B, will directly disclose some
>capability to A, but will only wield it indirectly for B. The only
>difference is that by reifying this right in the operational semantics
>it becomes possible to do information flow analysis without analyzing
>the code of S. We haven't exited the capability model at all here. It is
>merely an optimization.

I'm afraid you lost me in the above.  As I understand what you wrote
above, any subject (process/active object) with the capability "B"
(I'm not quite clear if B is a capability or not) can communicate
it.  That fits my understanding of the base object-capability
paradigm.  When you say "conceptually equivalent", to me they
seem to differ in that in one instance a subject has a capability
that can be communicated and in the other a subject has a capability
that can't be communicated (violating the base object-capability
paradigm - in my book anyway).

>However, this optimization is important because it supports two other
>things that we want: (1) it makes it possible for all mapping-related
>metadata (i.e. page tables a.k.a. nodes) to be explicitly allocated,
>which is necessary for proper storage accountability (2) it makes
>possible the implementation of a particular form of encapsulation that
>is essential to user-level pagers: the pager must provide a space to the
>client, but for practical implementation it must be able to know that
>the client cannot corrupt (i.e. alter) the metadata managed by the
>pager.

I guess that puts the discussion beyond that appropriate for cap-talk.
I'd be surprised if such needs couldn't be met with mechanisms that
stay within the base object-capability paradigm (if I have a capability,
then I can pass it as a parameter in an invocation), but if we have
to delve into design issues for user-level pagers, then I think it
would take us too far afield - though I take up some of your other
comments in separate messages.

--Jed  http://www.webstart.com/jed-signature.html