Rights Amplification

[Marcus Brinkmann]

At Tue, 14 Jun 2005 11:10:22 +0200,
Bernhard Kauer <kauer at os.inf.tu-dresden.de> wrote:
> 
> > We are turning in circles.  This is exactly the same model as you
> > suggested in your first reply.  And it is exactly the model I have
> > already tried to implement, and that we rejected because of
> > performance, wrong security properties, impossibility of transparent
> > interposition, code complexity, etc.
> 
> I forgot to explain why I switched back to the initial model.
> We have here 2 models in our discussion:
> 
> 1. Using a 1:1 mapping between objects and endpoints. This requires a
>    cmp() function.
> 
> 2. Using the features of L4.sec (local names, endpoints and badges) to
>    implement a capability system in user-level.

I think that is a fair representation of the two branches of the discussion.
 
> We all agree that the first one can be build, looking from a functional
> point of view. This does not mean that it is the best solution.
> 
> Or in other words some disadvantages (waste kernel memory, needs an 
> additional kernel operation,...) leads to the question whether the
> second model could also be built.

It was my understanding that it is an essential part of the design
roadmap for both of the two upcoming L4 designs that some kernel
memory is managed in user space.

You already make the concession that users can allocate kernel memory
by creating communication end points.  It doesn't make much sense to
me to now say that this should be restricted to a very small number of
such allocations per task.  In either case this is something that
should be regulated by user space policy, and not by the kernel.
Otherwise this indicates again a defect (of a different type) in your
design.

L4 X.2 had only one way for a user to allocate kernel memory, by
sending a mapping from one address space to another, and that could be
restricted by using a redirector.  So it was quite safe, although
there was still a defect: There was no way for a memory manager to
reliably know how much kernel memory was needed for a given users
mappings.  So, there is some argument to be made that even without
L4.sec the memory management model of the L4 kernel is underdeveloped.

In fact, I think that to become a mature product, L4 must solve the
kernel memory problem in a fundamental way, because in a production
system having the kernel crash because it is out of memory is a major
issue.

The need for an additional kernel operation should concern you.  But
it is my opinion that this is in fact a clue that there is a whole
area of endovement in which L4 is underdesigned, and a great
opportunity for the L4 group to explore.  But of course I first need
to convince you that the alternative is not an option ;)

> Perhaps we should split the discussion here and try to answer in one 
> thread the question of the first model (e.g. why cmp() and not
> map_lookup(),...)
> and in another one the problems with the second model you mention
> in your last mail.

I would be more than happy with that.

Thanks,
Marcus