OT: Can We Make OSes Reliable and Secure

[Robert Brockway]

On Mon, 5 Jun 2006, Lennart Sorensen wrote:

> Then what took Hurd so long?

Disagreements, lack of direction, general human related problems that can 
derail even the best project.

>> Sure.  Because a lot of hard work has gone into it.  I am emphasising that
>> it is simply easier to make a microkernel system stable.
>
> Well other than QNX, I am still waiting to see a successful microkernel
> system that gets used.

OS-9 (not Mac OS9 but Microware OS-9)

> Well the unix user space is excelent.  Little tools (modular design
> after all) that do one thing well, working together is great.  Of course

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.

> there is no reason a microkernel based system couldn't use the same user
> space, and work great.

Yes, very true.  In fact I fully expect the popular MK (microkernel) 
systems of the coming decades to fully support a Linux 
look-alike environment among others.

I've alluded to this a bit in earlier posts:

My view of future OSes is MK based systems with low level services 
(functions we'd now have in a monolithic kernel) running in userspace and 
the ability to simulataneously abstract a large number of environments 
cleanly and have them talk.  What we today call virtualisation would only 
be a subset of the abstraction I'm talking about.

In an MK (in general) you lose in performance but you gain in stability 
and flexibility.  Experiments in the area show the performance loss is 
usually no more than 10% for an MK.  A well designed MK like recent 
versions of the L4 family can actually perform better than a monolithic 
kernel in some cases.

> If I was to accidentally byte swap some data in one module (say it's a
> module that does caching) before sending it to the filesystem module,
> there is nothing the filesystem module can do to save me.  Bugs are
> bugs, and they will hurt data in some cases.

If the caching module passes bad data, yes that could cause corruption. 
It also has nothing to do with my original assertion...

This part of the discussion arose when I pointed out that tampering in one 
part of a monolithic kernel broke another part.  I was (and still am) 
talking about code changes, not corrupt data.

No amount of tampering in one module will corrupt code in another module 
of a well designed MK system.  As they only communicate through a well 
defined protocol there remains integrity in the commands exchanged between 
the modules.  For example a buffer-cache module could only ask the 
filesystem module to do specific actions (flush block X to disk now, 
whatever).  The language the modules speak can be arbitrarily constrained.

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.

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.
--
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