From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,6394e5e171f847d1
X-Google-Attributes: gid103376,public
X-Google-ArrivalTime: 2001-09-05 13:14:31 PST
Path: 
 archiver1.google.com!newsfeed.google.com!newsfeed.stanford.edu!news-spur1.maxwell.syr.edu!news.maxwell.syr.edu!nntp.abs.net!cpk-news-hub1.bbnplanet.com!chcgil2-snf1.gtei.net!news.gtei.net!news.binc.net!kilgallen
From: Kilgallen@SpamCop.net (Larry Kilgallen)
Newsgroups: comp.lang.ada
Subject: Re: Ada OS Kernel features
Date: 5 Sep 2001 15:14:29 -0500
Organization: LJK Software
Message-ID: <wjwKHdGfRR9P@eisner.encompasserve.org>
References: <9n4euv$t9m$1@slb6.atl.mindspring.net>
 <3B964C7A.BC04374E@icn.siemens.de> <9n5o9n$37a$1@slb7.atl.mindspring.net>
 <3%ul7.3362$9z1.440040@news6-win.server.ntlworld.com>
NNTP-Posting-Host: eisner.encompasserve.org
X-Trace: grandcanyon.binc.net 999720871 16173 192.135.80.34 (5 Sep 2001
 20:14:31 GMT)
X-Complaints-To: abuse@binc.net
NNTP-Posting-Date: Wed, 5 Sep 2001 20:14:31 +0000 (UTC)
Xref: archiver1.google.com comp.lang.ada:12770
Date: 2001-09-05T15:14:29-05:00
List-Id: <comp.lang.ada>

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.