[cap-talk] Concening entry "ambient authority" in Wikipedia

[Mark Miller]

On Wed, Jun 10, 2009 at 5:50 AM, Marcus Brinkmann <
marcus.brinkmann at ruhr-uni-bochum.de> wrote:

>
> > To quote the Wikipedia page:
> >
> > "An address can be obtained by: 1. creation: creating a new object ...
> > 2. receiving a message ... *all* computation is performed following the
> > above rules."
> >
> > If there are memory pages that aren't optional, they are received by
> > some means other than the above.
>
>

EVERYONE, PLEASE STOP USING THE WIKIPEDIA PAGE AS AUTHORITATIVE!

The restatement of the ocap model on this page reproduces the mistakes of
Paradigm Regained and the Actor locality laws. As I mentioned previously, I
have tried to update the citation on this page to instead cite my thesis.
But after this was anonymously reverted several times, I got tired of
playing reversion wars. Please don't let my fatigue, or the comparatively
greater energy of anonymous wikivandals, determine the authoritative
definition of the object-capability model.

The crucial concept left out of these earlier expressions is "Loader
Isolation", explained in Section 10.3 of my thesis. My apologies again for
how badly Chapter 10 is written. I hope someone will someday attempt a more
coherent restatement.


Part of Marcus' criticism is partially correct:

Section 10.3:

> The E loader does honor a few magic names, but the associated values
>> provide no
>> authority. In Figure 10.2, the loader calls need not actually include “E”,
>> “throw”, “true”,
>> or “false”, as the loader will resolve these magic names to their well
>> known values, none of
>> which provide authority. Although this violates our model and should be
>> fixed, it is mostly
>> harmless. The E loader also considers itself mostly harmless, and provides
>> magic access to
>> itself.
>>
>
The key reason we allowed ourselves this cheat is the "none of which provide
authority" qualifier. That's also why I used the term "authority bearing" in
my earlier quote that Marcus is responding to:

> If authority bearing capabilities are necessarily widely held, i.e.,
> if A loading and instantiating code B cannot deny such capabilities to
> B, then you don't have an object-capability system.

5 is not authority bearing. Possessing a 5 does not allow the holder to
cause any effects on the world outside itself. The last part of section 10.4
makes the connection between what capabilities (like 5) may be safely
undeniable and Popek & Goldberg's earlier work explaining what kinds of
instructions may safely be user-mode instructions without violating "full
virtualizability".

Regarding 7 specifically, section 9.1 states:

We distinguish three kinds of primitive objects.
>> 1. Data objects, such as the number 7. Access to these are knowledge
>> limited rather
>> than permission limited. If Alice can figure out which integer she wants,
>> whether 7 or
>> your private key, she can have it. Data provides only information, not
>> access. Because
>> data is immutable, we need not distinguish between a reference to data and
>> the data
>> itself. (In an operating system context, we model user-mode compute
>> instructions as
>> data operations.)
>>
>
I leave it as an exercise for the reader to figure out how to generalize
this to cover 5 ;).

-- 
Text by me above is hereby placed in the public domain

   Cheers,
   --MarkM
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/cap-talk/attachments/20090610/37ec509f/attachment-0001.html