By: Rob Thorpe (robert.thorpe.delete@this.antenova.com), May 16, 2006 12:22 am
Room: Moderated Discussions
Linus Torvalds (torvalds@osdl.org) on 5/15/06 wrote:
---------------------------
>Linus Torvalds (torvalds@osdl.org) on 5/15/06 wrote:
>>
>>I'd worry about some really smart kid in some random country
>>that I've never heard of, who just doesn't know how hard
>>things are, and who is hungry for the challenge, and decides
>>to "just do it". And does things differently (in some
>>respect - maybe he decides that the real problem is the
>>language, and writes a much better model for handling all
>>the complex issues).
>
>Btw, I'm not just saying that. I think the success of Unix
>and the fact that it is intertwined with C and implemented
>in C-like languages (where C++ very much counts as C-like),
>is not just a random historical oddity.
>
>If you want to change the OS model, I don't think that
>microkernels is where it is at. A really different model
>for how you state the problems and solutions might be it,
>though. In that sense, Java (and that whole virtual
>machine model, and yes, I realize it wasn't new to java
>per se) is much more likely to make more of a difference.
>
>The whole protection model (and thus largely security
>model) of UNIX/C depends on mutual distrust of independent
>entities, and that involves some real costs in the form
>of hardware protection domains. The microkernel issue takes
>that notion of protection domains further, and makes it
>much worse.
>
>But that's not actually the only model. You can certainly
>have your protection model defined by the language, and
>be able to "securely" call across protection domains without
>any run-time costs if you can show the accesses to be
>statically safe through the language interfaces used.
>
>Of course, that has its own set of downsides, and for a
>really secure system you probably want both - true security
>is often a set of layers, with "if the bad guys get through
>one layer, they'll be stopped by the next one or the one
>after that", where you end up hoping that any security
>issues at different layers are not related.
You could do something like this:
* Have a kernel containing the most essential things, scheduler, start-up etc.
* Have a small compiler hooked to the kernel capable of compiling from some simple intermediate language into machine code. (Maybe it need not be in the kernel)
* Have less core things, like device drivers, and file systems held in intermediate code.
When a sub-system is needed it is compiled. To compile it there is a function something like
compiler (code_block, allowable_mem_accesses, allowable_io, etc);
I.e. the compiler takes as argument what memory and IO the code is permitted to access. It then compiles the code with those limits. Anything it statically verifies are inside the limits is compiled directly, for anything it can't it inserts checks.
The compilation could be done for device drivers etc when their memory spaces are known. Which may be boot time or build time or some other time later.
This seems a complex way to go about the problem, the compiler would have to be good. But there again most kernels are fairly complex anyway.
---------------------------
>Linus Torvalds (torvalds@osdl.org) on 5/15/06 wrote:
>>
>>I'd worry about some really smart kid in some random country
>>that I've never heard of, who just doesn't know how hard
>>things are, and who is hungry for the challenge, and decides
>>to "just do it". And does things differently (in some
>>respect - maybe he decides that the real problem is the
>>language, and writes a much better model for handling all
>>the complex issues).
>
>Btw, I'm not just saying that. I think the success of Unix
>and the fact that it is intertwined with C and implemented
>in C-like languages (where C++ very much counts as C-like),
>is not just a random historical oddity.
>
>If you want to change the OS model, I don't think that
>microkernels is where it is at. A really different model
>for how you state the problems and solutions might be it,
>though. In that sense, Java (and that whole virtual
>machine model, and yes, I realize it wasn't new to java
>per se) is much more likely to make more of a difference.
>
>The whole protection model (and thus largely security
>model) of UNIX/C depends on mutual distrust of independent
>entities, and that involves some real costs in the form
>of hardware protection domains. The microkernel issue takes
>that notion of protection domains further, and makes it
>much worse.
>
>But that's not actually the only model. You can certainly
>have your protection model defined by the language, and
>be able to "securely" call across protection domains without
>any run-time costs if you can show the accesses to be
>statically safe through the language interfaces used.
>
>Of course, that has its own set of downsides, and for a
>really secure system you probably want both - true security
>is often a set of layers, with "if the bad guys get through
>one layer, they'll be stopped by the next one or the one
>after that", where you end up hoping that any security
>issues at different layers are not related.
You could do something like this:
* Have a kernel containing the most essential things, scheduler, start-up etc.
* Have a small compiler hooked to the kernel capable of compiling from some simple intermediate language into machine code. (Maybe it need not be in the kernel)
* Have less core things, like device drivers, and file systems held in intermediate code.
When a sub-system is needed it is compiled. To compile it there is a function something like
compiler (code_block, allowable_mem_accesses, allowable_io, etc);
I.e. the compiler takes as argument what memory and IO the code is permitted to access. It then compiles the code with those limits. Anything it statically verifies are inside the limits is compiled directly, for anything it can't it inserts checks.
The compilation could be done for device drivers etc when their memory spaces are known. Which may be boot time or build time or some other time later.
This seems a complex way to go about the problem, the compiler would have to be good. But there again most kernels are fairly complex anyway.
Topic | Posted By | Date |
---|---|---|
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 03:41 PM |
Hybrid (micro)kernels | S. Rao | 2006/05/08 05:14 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/08 05:16 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/08 06:21 PM |
Hybrid (micro)kernels | nick | 2006/05/08 06:50 PM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 12:26 AM |
There aren't enough words... | Rob Thorpe | 2006/05/09 01:39 AM |
There aren't enough words... | Tzvetan Mikov | 2006/05/09 02:10 PM |
There aren't enough words... | Rob Thorpe | 2006/05/14 11:25 PM |
Hybrid (micro)kernels | Tzvetan Mikov | 2006/05/09 10:17 AM |
Hybrid (micro)kernels | Bill Todd | 2006/05/09 03:05 PM |
Hybrid (micro)kernels | rwessel | 2006/05/08 10:23 PM |
Hybrid kernel, not NT | Richard Urich | 2006/05/09 05:03 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 06:06 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 06:40 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 07:30 AM |
Hybrid kernel, not NT | Rob Thorpe | 2006/05/09 08:07 AM |
Hybrid kernel, not NT | _Arthur | 2006/05/09 08:36 AM |
Linux vs MacOSX peformance, debunked | _Arthur | 2006/05/18 06:30 AM |
Linux vs MacOSX peformance, debunked | Rob Thorpe | 2006/05/18 07:19 AM |
Linux vs MacOSX peformance, debunked | Anonymous | 2006/05/18 11:31 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 07:16 AM |
Hybrid kernel, not NT | Andi Kleen | 2006/05/09 01:32 PM |
Hybrid kernel, not NT | myself | 2006/05/09 02:24 PM |
Hybrid kernel, not NT | myself | 2006/05/09 02:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/09 04:26 PM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 07:06 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 12:35 AM |
Hybrid kernel, not NT | nick | 2006/05/13 03:40 AM |
Hybrid kernel, not NT | Brendan | 2006/05/13 08:48 AM |
Hybrid kernel, not NT | nick | 2006/05/13 06:41 PM |
Hybrid kernel, not NT | Brendan | 2006/05/13 08:51 PM |
Hybrid kernel, not NT | nick | 2006/05/14 04:57 PM |
Hybrid kernel, not NT | Brendan | 2006/05/14 09:40 PM |
Hybrid kernel, not NT | nick | 2006/05/14 10:46 PM |
Hybrid kernel, not NT | Brendan | 2006/05/15 03:00 AM |
Hybrid kernel, not NT | rwessel | 2006/05/15 06:21 AM |
Hybrid kernel, not NT | Brendan | 2006/05/15 07:55 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/15 08:49 AM |
Hybrid kernel, not NT | nick | 2006/05/15 03:41 PM |
Hybrid kernel, not NT | tony roth | 2008/01/31 01:20 PM |
Hybrid kernel, not NT | nick | 2006/05/15 05:33 PM |
Hybrid kernel, not NT | Brendan | 2006/05/16 12:39 AM |
Hybrid kernel, not NT | nick | 2006/05/16 01:53 AM |
Hybrid kernel, not NT | Brendan | 2006/05/16 04:37 AM |
Hybrid kernel, not NT | Anonymous | 2008/05/01 09:31 PM |
Following the structure of the tree | Michael S | 2008/05/02 03:19 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 04:31 AM |
Following the structure of the tree | Michael S | 2008/05/02 05:02 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 05:48 AM |
Following the structure of the tree | Dean Kent | 2008/05/02 08:14 AM |
Following the structure of the tree | David W. Hess | 2008/05/02 09:05 AM |
LOL! | Dean Kent | 2008/05/02 09:33 AM |
Following the structure of the tree | anonymous | 2008/05/02 02:04 PM |
Following the structure of the tree | Dean Kent | 2008/05/02 06:52 PM |
Following the structure of the tree | Foo_ | 2008/05/03 01:01 AM |
Following the structure of the tree | David W. Hess | 2008/05/03 05:54 AM |
Following the structure of the tree | Dean Kent | 2008/05/03 09:06 AM |
Following the structure of the tree | Foo_ | 2008/05/04 12:06 AM |
Following the structure of the tree | Michael S | 2008/05/04 12:22 AM |
Hybrid kernel, not NT | Linus Torvalds | 2006/05/09 04:19 PM |
Microkernel Vs Monolithic Kernel | Kernel_Protector | 2006/05/09 08:41 PM |
Microkernel Vs Monolithic Kernel | David Kanter | 2006/05/09 09:30 PM |
Sigh, Stand back, its slashdotting time. (NT) | Anonymous | 2006/05/09 09:44 PM |
Microkernel Vs Monolithic Kernel | blah | 2006/05/12 07:58 PM |
Microkernel Vs Monolithic Kernel | Rob Thorpe | 2006/05/15 12:41 AM |
Hybrid kernel, not NT | AnalGuy | 2006/05/16 02:10 AM |
Theory versus practice | David Kanter | 2006/05/16 11:55 AM |
Distributed algorithms | Rob Thorpe | 2006/05/16 11:53 PM |
Theory versus practice | Howard Chu | 2006/05/17 01:54 AM |
Theory versus practice | JS | 2006/05/17 03:29 AM |
Play online poker, blackjack !!! | Gamezonex | 2007/08/16 12:49 PM |
Hybrid kernel, not NT (NT) | atle rene mossik | 2020/12/12 08:31 AM |
Hybrid (micro)kernels | philt | 2006/05/14 08:15 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 07:20 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 10:56 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 12:22 AM |
Hybrid (micro)kernels | rwessel | 2006/05/16 10:23 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/16 11:43 PM |
Hybrid (micro)kernels | rwessel | 2006/05/17 12:33 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/19 06:51 AM |
Hybrid (micro)kernels | rwessel | 2006/05/19 11:27 AM |
Hybrid (micro)kernels | techIperson | 2006/05/15 12:25 PM |
Hybrid (micro)kernels | mas | 2006/05/15 04:17 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/15 04:39 PM |
Hybrid (micro)kernels | Colonel Kernel | 2006/05/15 08:17 PM |
Hybrid (micro)kernels | Wink Saville | 2006/05/15 09:31 PM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 09:08 AM |
Hybrid (micro)kernels | Wink Saville | 2006/05/16 08:55 PM |
Hybrid (micro)kernels | rwessel | 2006/05/16 10:31 AM |
Hybrid (micro)kernels | Linus Torvalds | 2006/05/16 11:00 AM |
Hybrid (micro)kernels | Brendan | 2006/05/16 12:36 AM |
Hybrid (micro)kernels | Paul Elliott | 2006/09/03 07:44 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/09/04 08:25 AM |
Hybrid (micro)kernels | philt | 2006/05/15 11:55 PM |
Hybrid (micro)kernels | pgerassi | 2007/08/16 06:41 PM |
Another questionable entry on Wikipedia? | Chung Leong | 2006/05/18 09:33 AM |
Hybrid (micro)kernels | israel | 2006/05/20 03:25 AM |
Hybrid (micro)kernels | Rob Thorpe | 2006/05/22 07:35 AM |