[cap-talk] capability copy and capability map

[Marcus Brinkmann]

At Wed, 25 Oct 2006 13:28:35 +0200,
Neal H. Walfield wrote:
> 
> At Tue, 24 Oct 2006 13:30:29 -0700,
> Charles Landau wrote:
> > I'm not sure which pattern you are referring to.
> > 
> > EROS/CapROS/etc permits capability copy (by default), and also allows 
> > you to explicitly choose L4-style revocation (by, for example, 
> > granting a wrapper object built from your own space bank). Thus you 
> > have the choice of either pattern. L4 appears to force one pattern, 
> > since I don't know how to support capability copy on L4.

As far as I understand, EROS limits the number of wrappers in a chain
to some small fixed number (4?), as the chain is resolved at each
invocation, and the send operation needs to be bounded in time.

In L4, the tradeoff is different: There, the map and send operations
are constant in time, while the cost is pushed into the unmap
operation.  Thus, because the depth of the mapping tree can not be
restricted, unmap is not appropriate for real-time threads [Voelp].

Because of the restriction in EROS, wrapping is not a meaningful
design paradigm for large scale system construction in that system.
It is limited to narrow applications, for example privileged processes
(which have intimate knowledge about the expected nesting depth), and
puts a limit to the nesting of, for example, virtual machine monitors.
This is reflected by the fact that systems built on EROS etc use
capability copy dominantly.  In L4, capability map is a useful concept
for a much wider range of applications, so the map operation is used
dominantly in L4 system designs.

According to the L4 group in Dresden, L4 can easily support a
capability copy operation, with or without proper kernel resource
management.  However, it is currently rejected because no relevant,
convincing use cases are known.  L4 system designers will usually try
to change the source of the capability to the parent to avoid a
capability copy.  Ie, if A maps a capability to B and B wants to map
it to C, what is encouraged in L4 is to instead have A map the
resource to C directly, on behalf of B.  [Kauer] gives some examples.

The challenge by the L4 people is to find a use case of capability
copy that can not be avoided by a different overall system design.  As
with any paradigm shift, L4 tries to find its own local minimum in the
design space.

[Voelp] Design and Implementation of the Recursive Virtual Address
        Space Model for Small Scale Multiprocessor Systems by Marcus Völp
        http://i30www.ira.uka.de/teaching/theses/l4ka/index.php?lid=en&year=2002&docid=814
[Kauer] L4.sec Implementation --- Kernel Memory Management
        by Bernhard Kauer
        http://os.inf.tu-dresden.de/project/finished/finished.xml.en#kauer-diplom

Thanks,
Marcus