OS design...

[Ian Bicking]

Ray Dillinger writes:
> >That's fine, if only the admission control can check security.
> >In a low-level system, that's quite a costly feat.
> >In a high-level system, it's just a very particular case
> >of dynamic compilation.
> 
> Not quite. In any system, you have code you trust and code you
> don't trust.  Dynamically compiling the code you don't trust
> into the code you trust is one of many possible "Wrong Things". 
> A user can punch raw hex values into any location in any file
> his shell's credential allows him to write, including
> executables, using a hex editor.  Yes, it's a dangerous thing,
> but it is sometimes a useful thing.  If it is possible to
> write code (even using a hex editor) that forces the operating
> system to compromise itself (make hash of its process table,
> allow a process to terminate without reclaiming the memory and
> other resources allocated to it, become deadlocked, etc), then
> there is an error in the operating system. If it is not possible
> for a user to write her own compiler (which may contain errors) 
> then you have placed handcuffs on the usefulness of your system. 

I don't think it has to be that way.  First, you can simply disallow
editing of post-compiled code.  It really isn't very useful to edit
that code so you've placed few restrictions on the user -- certainly
not any restrictions that justify implementing a big security model.
To disallow editing is simple -- just a matter of write protection.

As I would see "dynamic compiling" working, you'd have something that
looks very close to real machine instructions, but has some guards to
ensure certain sorts of safety.  These can be things that allow
OS-level garbage collection, safety in the address space, and so on.
If you wanted something really spiffy, it might abstract certain
things as well, such as object-persistance (this would add a lot of
weight to the process, though, so it might not be worth it at this
level).  Compiling this psuedo-machine-code (which need not be
portable) to actual machine-code should be fairly easy and fast.  The
resulting executable can be cached or saved on disk to make the
process quite inexpensive.

A user can write their own compiler, it's just that it would compile
into this psuedo-machine-code.  This should give as much flexibility
to the compiler-writer as they deserve -- i.e., to make the code they
want but not to make anything that can compromise the system.

To me, it sounds like a kind of neat idea that would simplify the
operating system tremendously (on the low level) while having few
negative ramifications.  Getting rid of the possibility of
pointer-arithmetic just seems like it can simplify a lot of things.


<------------------------------------------------------------------->
< Ian Bicking                 |  bickiia@earlham.edu                >
< drawer #419 Earlham College |  http://www.cs.earlham.edu/~bickiia >
< Richmond, IN 47374          |  (765) 973-2824                     >
<------------------------------------------------------------------->