-----Original Message----- From: Jonathan S. Shapiro [mailto:shap@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: http://l4ka.org/projects/pistachio/l4-x2-r4.pdf. 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
general.
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)
IPCs.
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
book-keeping
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 losses?
- Volkmar
Volkmar Uhlig wrote:
-----Original Message----- From: Jonathan S. Shapiro [mailto:shap@eros-os.org]
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.
This discussion is going down strange roads ...
Volkmar, I strongly disagree with you here. One of the main motivations - if not _the_ main motivation together with fault isolation - to invent L3 and L4 has been security. Isolation using address spaces will unavoidably cost a few cycles and can ultimately justified by (fault isolation and) security arguments only. We do not build micro-kernels just for wrist watches, and - as Jonathan pointed out correctly - for cell phones you need a sound security model. And L4 does not have one and hence needs one. In Dresden, we are aware of this situation since very long time and have to act _now_ because we in Dresden have excellent opportunities to push the usage of L4 into security domains. We have to stop looking at the kernel interface just from the point of view of kernel hackers counting cycles!
BTW, the perception that Jochen Liedtke considered speed to dominate everything else (see some earlier email) is simply rubbish. Jonathan's statement "that performance cannot be used to justify fundamental insecurity" could as well originate from Jochen Liedtke.
--hermann
l4-hackers@os.inf.tu-dresden.de
-
Hermann Härtig -
Volkmar Uhlig