Split Capabilities: Making Capabilities Scale

[Karp, Alan]

Exactly right.  Using names as designators opens up so many problems that
the approach is not viable.  Capabilities must be associated with
designators that have nothing to do with names used by clients.
Unfortunately, that leaves no option but to have at least one capability per
object, i.e., no wildcards.  That may not be a problem for capability OSes
like EROS, but I believe it is when capabilities are cryptographically
secure certificates.  

Split capabilities let me build a secure environment with fewer than one
capability per resource by adding one level of indirection.  This
indirection is orthogonal to the one you describe.  Instead of having the
capability point directly to the object, e-speak Beta 2.2 has the object
point indirectly to the access rights part of the capability.

_________________________
Alan Karp
Decision Technology Department
Hewlett-Packard Laboratories MS 1U-2
1501 Page Mill Road
Palo Alto, CA 94304
(650) 857-3967, fax (650) 857-6278


> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
> Sent: Sunday, July 09, 2000 7:10 PM
> To: Karp, Alan; Mark S. Miller
> Cc: e-lang@eros-os.org
> Subject: Re: Split Capabilities: Making Capabilities Scale
> 
> 
> > In a conventional capability system, the capability *is* 
> the designation
> of
> > the object it refers to.
> 
> This depends on whether the system is partitioned or not. 
> Strictly speaking,
> in a partitioned capability system the designation is of the 
> "slot" in which
> the capability resides. That is, there is one added level of 
> indirection.
> 
> I am beginning to suspect that the source of confusion in the 
> discussion
> rests on what may be a confusion about the primacy of 
> file-system names as
> opposed to object designators. By "name", I mean a string that is
> (conventionally) handed to a file system via an "open" call 
> in order to
> obtain a file descriptor. By "designator", I mean either a 
> file descriptor
> or a capability depending on what systems we are talking 
> about. Note that
> the operating system (equivalently: the runtime) need not 
> know *anything*
> about names. It can operate purely in terms of designators. 
> There is no
> reason why one mapping of names to designators is better than 
> any other,
> provided that all protection decisions are made at the 
> designator level.
> 
> The wildcarding approach, unless I am terribly confused, 
> works on names
> rather than designators. It therefore places protection at 
> the level of
> names rather than designators. If so, the resulting system is not a
> capability system at all: a critical protection decision appears to be
> omitted in the designator layer of the system architecture. 
> There is no harm
> in *also* checking things at the name level, but this is 
> perilous. Once a
> designator is obtained it may be held for an arbitrarily long time.
> 
> In real system construction, however, there is a problem with 
> being purely
> designator driven, which is the "boostrap problem". In the absence of
> persistence, determining who gets what initial capabilities 
> at powerup is
> distressingly hard to get right. Ultimately, this is *why* we 
> have built
> file systems into most conventional computing architecture.
> 
> Is there any light here, or am I just adding to the murk?
> 
> shap
>