RE: L4, High Assurance, and Protection
-----Original Message----- From: Hermann Härtig [mailto:haertig@os.inf.tu-dresden.de] Sent: Tuesday, January 06, 2004 11:07 AM
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.
The hitserver is an example where this perception is not rubbish (as you phrased it). The point I tried to make is that if you want generality of the kernel you have to look at a wide area of applications. As I stated in previous emails, I'm aware of the insufficiencies of the security model in L4 and I believe that this is well taken care of by many people looking at. The same is not true for the performance aspects and my feeling is that "all these important security features" are used to fatten and to slow the kernel unreasonably. Since you referred to Jochen here a quote from "Improving IPC by kernel design": "IPC performance is the Master. Anything which may lead to higher IPC performance has to be discussed. In case of doubt, decisions in favor of IPC have to be taken. But the performance and security qualities of other components must not be seriously impacted." So far there is no sound model proposed which doesn't add significant overhead and which has the same elegance as L4 today. - Volkmar
On Tue, 6 Jan 2004 13:15:50 +0100, "Volkmar Uhlig" <volkmar@ira.uka.de> said: -----Original Message----- From: Hermann Härtig [mailto:haertig@os.inf.tu-dresden.de] Sent: Tuesday, January 06, 2004 11:07 AM
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.
VU> The hitserver is an example where this perception is not rubbish (as you phrased it). VU> The point I tried to make is that if you want generality of the VU> kernel you have to look at a wide area of applications. As I VU> stated in previous emails, I'm aware of the insufficiencies of the VU> security model in L4 and I believe that this is well taken care of VU> by many people looking at. The same is not true for the VU> performance aspects and my feeling is that "all these important VU> security features" are used to fatten and to slow the kernel VU> unreasonably. Hmm, Volkmar, I have to agree with Hermann. One of the core tenets of OS designers should be that performance cannot buy security, and an OS without security is worthless. And security isn't optional. To use your wristwatch example: Someone who really doesn't want security is going to use a microcontroller without MMU, and hence not run L4. If you have an MMU, you worry (almost by definition) about security. And the wristwatch examples are on the way out: just about any embedded system under development now or in the near future (and that is an important part of the L4 market) is being networked, and hence must worry about security. There are much stronger drivers of kernel-bloat than security at the moment. Multiprocessor scalability (up _and_ down) for example. VU> Since you referred to Jochen here a quote from "Improving IPC by kernel design": VU> "IPC performance is the Master. Anything which may lead to higher IPC performance has to be discussed. In case of doubt, decisions in favor of IPC have to be taken. But the performance and security qualities of other components must not be seriously impacted." Jochen said other things that have been proven wrong in the meantime. For example "a microkernel must be unportable", as you guys have shown ;-) The above quoted statement must be seen in the context of improving IPC performance by more than an order of magnitude over predecessors, by taking a radical approach. An OOM cannot be hidden at application level. Howver, 10% performance difference at the microkernel API will be difficult to detect at the application level (you remember the work on small address spaces?) And I definitely agree with Jon: It's end-to-end performance that counts. Microbenchmarks are great for analysis, but worthless for users. VU> So far there is no sound model proposed which doesn't add VU> significant overhead and which has the same elegance as L4 today. Clans-and-chiefs was "elegant" in a way, but it sucked so much that no-one used it. And some of the things in the X.2 API are much less elegant than previous versions (like the dreaded non-delegatable root task). Again, I cannot help agreeing with Jon (apologies for the misquote): if the API forces complexity on the system built on top, then the API is broken. (Which is just another variant of the end-to-end argument.) Gernot -- Gernot Heiser School of Computer Sci. & Engin. Professor of Operating Systems The University of NSW Phone: +61 2 9385 5156 UNSW SYDNEY NSW 2052, Australia Fax: +61 2 9385 7942 http://www.cse.unsw.edu.au/~gernot
"Gernot" == Gernot Heiser <gernot@cse.unsw.edu.au> writes:
VU> The point I tried to make is that if you want generality of the VU> kernel you have to look at a wide area of applications. As I VU> stated in previous emails, I'm aware of the insufficiencies of VU> the security model in L4 and I believe that this is well taken VU> care of by many people looking at. The same is not true for the VU> performance aspects and my feeling is that "all these important VU> security features" are used to fatten and to slow the kernel VU> unreasonably. Gernot> Hmm, Volkmar, I have to agree with Hermann. One of the core Gernot> tenets of OS designers should be that performance cannot buy Gernot> security, and an OS without security is worthless. And Gernot> security isn't optional. An important point here is that the we-don't-need-the-extra-security argument doesn't necessarily need to apply to the complete system. It may apply to only a subsystem, e.g., an "application" consisting of several address spaces that does not need any extra security mechanisms when communicating internally. Another example is a system where the device drivers and a number of other trusted services allow efficient, unrestricted object invokation in between each other, but object invocation from outside tasks/threads do need some security policy to be enforced. eSk
Volkmar Uhlig wrote:
-----Original Message----- From: Hermann Härtig [mailto:haertig@os.inf.tu-dresden.de] Sent: Tuesday, January 06, 2004 11:07 AM
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.
Since you referred to Jochen here a quote from "Improving IPC by kernel design": "IPC performance is the Master. Anything which may lead to higher IPC performance has to be discussed. In case of doubt, decisions in favor of IPC have to be taken. But the performance and security qualities of other components must not be seriously impacted."
No contradiction at all between JL: "security qualities of other components must not be seriously impacted." and JS:"performance cannot be used to justify fundamental insecurity" --hermann
participants (4)
-
Espen Skoglund -
Gernot Heiser -
Hermann Härtig -
Volkmar Uhlig