OT: Can We Make OSes Reliable and Secure

[Robert Brockway]

On Sun, 11 Jun 2006, Christopher Browne wrote:

> There are others, but little that's not pretty much curiosity.

OS-9 and QNX certainly aren't curiosities.  There has definately been lack 
of movement in the microkernel world up to this point (at least as far as 
production ready OSes go).  I don't think it is a particularly good basis 
for assuming there will not be movement in the microkernel world in the 
future.

>> That's part of the conceptual side which many OSes have taken on board (as
>> per my earlier posts).
>> 
>> There is cruft in *nix userspace.  Why exactly is the command to send a
>> signal to a process called "kill"? The name is historical but is defined
>> in POSIX now.  This one was highlighted to me just recently when I was
>> providing training on the shell and command line tools.
>
> That "kill" is poorly named is in no way a meaningful argument in
> favor of using a microkernel.  Similarly, the fact that people get
> confused as to why Unix often uses such directories as /bin, /sbin
> /usr/sbin, /usr/bin, and /usr/ucb to store differing programs is not a
> reason for switching to a microkernel.

Not did I ever asser it was :)  The conversation had wandered by this 
point.  If you go back you'll see I was pointing out that many unix 
concepts have been taken into more recent apps but the cruft had been left 
out.  I was giving examples of the cruft.  This applies equally well to 
microkernels and monolithic kernels.

> In Hurd, the notion of having all sorts of services managed as daemons
> separate from any central "kernel" is certainly an interesting one.
> In principle, that ought to allow restarting all sorts of services
> without needing to reboot.
>
> Of course, in practice, the Linux NFS server moved from a separate
> server into the kernel because this made it significantly faster.

True, but both are available.  Not surprisingly I use the user space nfsd 
if I can.

>> A well defined MK system would probably even put constraints on how
>> rapidly messages could be sent over the protocol to prevent an internal
>> DoS.
>
> The Dragonfly BSD folk are trying to head down this sort of road,
> using message passing (with choice of async/sync approaches).  Again,
> this is a monolithic kernel; there is little that people consider
> doing on microkernels that don't seem to benefit monolithic kernels...

That makes sense - most of the concepts should transfer fairly well, 
especially among disciplined monolithic kernel developers.

Discipline is a bit part of the problem IMHO.  Undisciplined microkernel 
developers may well discover their new module simply doesn't work.

Undisciplined monolithic kernel developers can touch enough bits of the 
kernel to make it work.  Discipline in this context can be imposed from 
above.

I ran across a great example recently.  Desiring proper per-user resource 
limits in the kernel I was reading up on recent efforts in that area. 
One developer was complaining about kernel developers within the Linux 
kernel avoiding code reuse and taking key resource allocation algorithms 
and planting them right within their own code.  Sometimes they are changed 
a little.  Anyone wanting to do good per-user resource management must 
consider all of the areas where resources are being allocated rather than 
one tightly defined area.

I think the discussion is starting to around in circles (inevitable in any 
thread this long).  I've said my piece and predict microkernels will 
become main stream in the future as their advantages outweight their 
disadvantages.  Only time will really tell.

Cheers,

Rob

-- 
Robert Brockway B.Sc.        Phone:          +1-905-821-2327
Senior Technical Consultant  Urgent Support: +1-416-669-3073
OpenTrend Solutions Ltd      Email:          support-wgAaPJgzrDxH4x6Dk/4f9A at public.gmane.org
                              Web:            www.opentrend.net
We are open 24x365 for technical support.  Call us in a crisis.

If you are emailing regarding an open ticket please consider
mentioning the ticket ID as this will assist us in responding
as quickly as possible.
--
The Toronto Linux Users Group.      Meetings: http://tlug.ss.org
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://tlug.ss.org/subscribe.shtml