Re: Extending the problems we have with caps to endpoints

[Jonathan S. Shapiro]

On Tue, 2005-10-11 at 20:09 +0200, Espen Skoglund wrote:

Good to hear from you, Espen!

[Jonathan S Shapiro]
> > For a while, I had them convinced that they wanted it. Then they
> > looked at the required interaction with the rest of the mapping
> > database and decided that it would be very difficult to add to their
> > existing system.
> 
> I'm not sure who you refer to as "they" here, but I for one have no
> recollection of seeing how this would be very difficult to add.  On
> the contrary, as far as I can see adding support for a copy operation
> only requires a couple of lines of code.  Note that I'm talking about
> the Pistachio implementation here, though.  The story might be
> different for the Fiasco people.

My memory of the discussion is now dim, but here it is:

In order to implement a COPY operation within the mapping database, the
L4 kernel would need to create a new database node that is parallel in
the mapping tree to the sender's mapping node. This new node then needs
to be inserted as a child of the sender node's parent node. I do not
recall the details at all, but there was something about this insert
that the Dresden team thought was very unpleasant.

I do not remember if they ever told me concretely why this should be so.
I am unclear on why this should be difficult myself, and I have not
looked at it myself. I have probably confused the description of the
problem in my memory. However, this will at least provide a place to
start to reconstruct it.

It may simply be that this introduced yet one more complexity, and the
shift to capabilities in L4sec was already becoming trickier than anyone
believed it would be at the beginning, and people felt this was
something that could be deferred for later.

> 
> > I have been saying for years that the right solution is to get rid
> > of MAP/UNMAP. For some strange reason, they have been mildly
> > reluctant to adopt this proposal. :-)
> 
> I should probably provide some answer/arguments on this...

Espen: it was a joke. Really. MAP/UNMAP is the single most distinctive
feature of L4. It would be impossible to remove it and still have L4 in
the eyes of your user base.

[Espen asks:]

> When you have a forwarding object that allows you to do a revokable
> copy, can the receiver of the copy operation detect that he's received
> a capability for a forwarding object?  My guess is "no".

The answer is definitely "yes", it CAN be detected.

>  And if this
> is the case, how is revoking the capability from the receiver in this
> way any worse than revoking the capability using unmap?

It isn't. I have some additional concerns that are specific to the
current definition of unmap having to do with implicit unmap on exit,
but I think these could be addressed. The question is which operation is
the common case and whether kernel storage allocation can be avoided in
the MAP operation. The answer to the "common case" question is heavily
tied to choices in the higher system design.

As I told my class today, the L4sec group is working on a design (kernel
heaps) that would resolve the kernel allocation concern and allow the
mapping database to be safely definitive. I am very eager to see what
happens with that approach.

If the kernel allocation issue can be resolved, then it becomes
perfectly okay to have both operations in the kernel (in my opinion). At
that point we only need to ask which one is the more common case and how
the respective operations should be tuned.

> Yes, I'm aware of the difference where the mapper terminates and
> implicitly unmaps the mapped capabilities.  What I was thinking about
> here was more the situation where the receiver of the capability
> relies on the capability not being able to in any way be revoked by
> the mapper/copier.  Have I missed some really crucial point?

None that I can see, except: because the receiver CAN detect a wrapped
capability, it can know that revocation is a concern.

Actually, it's even more complex than this, because the object can be
forcibly destroyed as a whole even if the specific capability cannot be
selectively revoked. So a paranoid application must consider *two*
issues:

  1. Can this specific capability be revoked?
  2. What durability contract exists with the storage allocator
     that provided the storage that the object occupies?

In most cases these issues can be removed from consideration by
structuring of object relationships. In the rest, they are quite
challenging.

I will add only that they are not challenging because of anything in the
structure of EROS or L4. They are challenging because these problems are
intrinsically complicated, and there is little experience that would
guide us in knowing the appropriate idioms for solving them securely.

shap