[cap-talk] On revocation and the use of wrappers and In Defenseof Identities

[Marcus Brinkmann]

At Sat, 09 Dec 2006 13:09:26 +0100,
"Valerio Bellizzomi" <devbox at selnet.org> wrote:
> 
> On 07/12/2006, at 17.35, Marcus Brinkmann wrote:
> 
> >At Thu, 07 Dec 2006 09:41:08 -0500,
> >"Jonathan S. Shapiro" <shap at eros-os.com> wrote:
> >> 
> >> On Thu, 2006-12-07 at 14:57 +0100, Marcus Brinkmann wrote:
> >> > > The server can always refuse if a given capability has been
> delegated
> >> > > too many times.
> >> > 
> >> > As Neal said.  Or: "What's too many?" [1]
> >> 
> >> I appreciate the humor, but there is a serious problem here in the OS
> >> context. If wrapping or delegation involves building a data structure,
> >> my bet is that data structure will grow linearly in the number of
> >> delegations.
> >
> >I can accept that assumption.
> >
> >> In order for the OS to have bounded-time operations, it MUST set a
> bound
> >> on the number of steps it will take in any given operation.
> >
> >Sure, that's an obvious truism.  But an operation can also be
> >preemptible, in which case it does not need to be bounded in time (at
> >least from the kernel's perspective).  Yes, this causes other
> >problems.  But it can be a viable design alternative.
> 
> The other problems you are referring to are really nasty for a real-time
> system like Coyotos. The nastiest problem is that if atomic operations
> aren't bounded in time you lose the guarantee of measurability of
> real-time accuracy.

Well, let's consider a real-time system like L4 Fiasco (from Dresden).
There this problem probably exists in the case of unmap() (I didn't
check the implementation, but it's a common problem across L4
implementations).  So, I agree that it is a nasty problem.

But if you consider my own, third, alternative implementation
suggestion, there it is not necessarily a problem, because unmap() can
probably be constant in time (just like in EROS/Coyotos).  Instead,
just like in EROS and Coyotos, it is the invocation operation that is
not bounded in time.  Or rather, it is bounded only by the depth of
delegation.  However, I can't see this as a problem, even in a
real-time scenario.  This is because you already need to be careful
about which capabilities you invoke in a real-time scenario.
Delegation depth is then just another property of the capability that
you need to be aware of.
 
> I'm not sure that unlimited delegation makes sense in any case. When you
> have delegated 10 or 20 times it is largely sufficient for any real job.

I am not sure either, but where do you take your confidence from?
Some time ago, it was thought sufficient to limit hostnames to 64
characters.  The people making the decision probably never had a
vacation in Wales.

> Already at 15 delegations you have somewhere 15 modules in your delegation
> chain, your application is very complex. What application would do that
> much delegation?

It's not necessarily complex.  Nesting, or hierarchies, exactly allow
for deep nesting without additional complication.  This is true for
example in the case of virtualization, where at any level of the
hierarchy the same interfaces are provided (thus, no additional
complexity occurs).

In a system build on virtualizable interfaces and revocable delegation
as primitives, I can easily see 5-7 layers of delegation in a single
instance of the operating system[1].  If that application then is a
virtual machine monitor that runs a second instance of the whole
operating system, something that is not uncommon today, you have 11-15
layers already.  Who am I to say that one layer of whole system
virtualization is enough for everybody?

[1] Example: This is more or less straight from my notes on design
    ideas for the Hurd operating system:
    Device Driver -> Device Driver Manager -> Terminal Instance
    -> Terminal Manager -> User Session Terminal Manager -> User Session Shell
    -> User Application -> Isolated Module in User Application

Thanks,
Marcus