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.