L4, High Assurance, and Protection

Volkmar Uhlig volkmar at ira.uka.de
Tue Jan 6 02:01:45 CET 2004

> -----Original Message-----
> From: Jonathan S. Shapiro [mailto:shap at eros-os.org] 
> Sent: Monday, January 05, 2004 9:31 PM
> I believe that I have now asked twice for a URL to this specification.
> Can you send me a URL? Otherwise we will continue to waste 
> each other's
> time. Please accept my apologies that, in the absence of this 
> document, I may have done so.
> If it was on one of the L4 web sites, I failed to see it.

On the l4ka.org homepage is a link to the latest snap shot (right now
rev. 5), or use that link:
The V4 spec is solely maintained in Karlsruhe.

> > You immediately run into replacement policy issues.
> If there is a faster way, great! But protection is not merely 
> a desire. It is a hard requirement. *Every* mechanism I know 
> about for achieving a protected interface carries a fundamental 
> cost somewhere. You can do it with address space traversal, or 
> you can accept the need for a replacement policy, or you can do 
> something else, but you are going to pay *somewhere*.

Or you are able to selectively choose to pay for it.

> My problem is that performance cannot be used to justify fundamental
> insecurity. Speed at the cost of correctness is simply unacceptable.

Agree in general, however there are application domains which don't want
to give up speed for an unused security model.  And you have to accept
that those apps exist, even if _you_ are not interested in those.

> > Here the argument is around IPC redirection (which is arguably
> > expensive).  By sticking an interceptor in between you know which
> > mappings go in and out.  That way you can control it.  But I suspect
> > that fine-grain control over mapping privileges makes sense.  The
> > question is what this granularity should be--page or mapping in
> From a security perspective, the problem is with the 
> presence of mapping operations at all. Mapping establishes a 
> high-speed, mutable channel, so it tends to undermine reference 
> monitors.

Of course you can't allow to permanently establish a page mapping but
have to interpose it.  However, nobody promised to have a
protocol-transparent reference monitor using page mappings....

> My preferred model is that performing a send with a mapping on a
> disabled descriptor would be treated as an access violation, and a
> suitable exception would be delivered to fault handler. I 
> don't want to pay any indirection cost for the legal (non-mapping)

See above.

> > You can transparently drop the mapping if it is not 
> allowed.  Since the
> > guarantees whether a page is mapped or not come from the 
> pager hierarchy
> > it is only as strong as all combined pagers.  By adding a
> > non-guaranteeing pager in the hierarchiy you are set.
> >From a security perspective, failing silently is *always* a 
> mistake. It
> also makes virtualization difficult if somebody wishes to be backward
> compatible with the interface later. You are describing a situation in
> which a sender has done a known-illegal operation, but no fault is
> generated? This doesn't seem like a good design.

Why?  You fault again--the client broke the protocol.  You can define a
protocol which does not allow page mappings.  If anybody tries--too bad.
Why do you care about virtualization and what virtualization do you have
in mind?  (I think it is more a Q of transparency.)

> It is a big problem for the pager to be settable by the thread. There
> are some systems in which this can be permitted, and other systems in
> which it **must not** be permitted. Because there exists systems in
> which this must not be permitted, the operation must (at a minimum)
> involve invocation of a trusted party.
> Perhaps there is some third design possibility that I have not
> considered carefully enough, but it appears to me that a 
> high-assurance system constructed on top of L4 must be built 
> exclusively using trusted pagers. While it is possible, in abstract, 
> to use untrusted pagers in a descriptor-based system (as EROS does), 
> the L4 map/grant operations don't appear to provide enough
> controls to be trusted.

I guess you have to give a little more information about that--maybe on
a whiteboard.  It is neither clear to me why this is a *must* nor why an
untrusted pager causes a problem.  

A Q regarding your hash/cache suggestion:  how do you ensure that you
can't use the cache as a covert channel without major performance

- Volkmar

More information about the l4-hackers mailing list