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

[Valerio Bellizzomi]

On 09/12/2006, at 21.57, Marcus Brinkmann wrote:

>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?

I'm not confident at all, it is just that I see unlimited delegation like
a potential denial-of-resource.
Walking back a delegation-chain will probably be slow if there are too
many levels of delegation.

>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.

How many characters are they now?

>
>> 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

Wait, with application I meant a user-level program.
In your example I can agree that 20 is probably not enought, but we still
have to choose a bound, perhaps a higher bound, but we need one.

>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
>
>_______________________________________________
>cap-talk mailing list
>cap-talk at mail.eros-os.org
>http://www.eros-os.org/mailman/listinfo/cap-talk