Re: Ada OS Kernel features

[Kilgallen@SpamCop.net (Larry Kilgallen)]

In article <3%ul7.3362$9z1.440040@news6-win.server.ntlworld.com>, "chris.danx" <chris.danx@ntlworld.com> writes:
> 
>> > You should be able to load/unload a driver dynamically (I hate rebooting
>> > because of driver change).
>>
>> Agreed.  This is not simple to implement, but it is well worth the trouble
>>
>> > You should be able to "overload" a driver. What I mean ?  Lets assume
>> > you have a simple grafic driver on bootup, then you load a "better"
>> > (more complex, higher resolution, 3D excelerator ...) one. If this one
>> > crashes, then it should simply be unloaded and the system should
>> > continue work with the (simple) default driver - instead of showing a
>> > "blue screen" ;-)
>>
>> My first reaction to this was "Not Possible".  However, that isn't
> entirely
>> true; it is just *VERY VERY* difficult.
> 
> Only in the "drivers in supervisor mode" model.
> 
>> A driver runs in kernel mode,
> 
> Why?  Why not just have it in user mode?  It makes more sense to have them
> in user mode, at least to me.  They can only corrupt themselves then, etc.

A driver is part of the TCB.  It cannot be part of the TCB in user mode.

(For anyone unfamiliar with the concept, the TCB is the Trusted Computing
Base which implements the security policy of the system.)

> I really don't get why a driver must have access to system structures or
> atleast those in kernel space, can you explain this?

A driver has access to raw hardware.  Therefore it necessarily has
access to the system -- it could rewrite the copy of the OS on disk
if it chose.