OT: Can We Make OSes Reliable and Secure

[Robert Brockway]

On Fri, 2 Jun 2006, Lennart Sorensen wrote:

> efficient and reasonable thing to do.  This also means it is harder to
> tear out and replace a subsystem in linux, although it isn't always that
> bad.  After all sometime in 2.4.x (I think x=10) the VM system was
> completely replace by someone elses code because the existing code
> didn't work well, and the new one was simpler, more obvious, and clearly
> worked.  The VM interface apparently is sufficiently abstracted that it
> could just be replaced all at once without having to touch other code
> that uses it.

My recollection of that event is that it was anything but clean.  It was 
quite a painful experience and took place over several months.  It's a 
perfect example of whatr I'm talking about - the monolithic design made 
the change hard.

> I think much of the breakage seen on linux is just as likely on a micro
> kernel system.  One thing the microkernel system is less liukely to see

I disagree.  A lot of problems have occured because the Linux kernel (and 
indeed any monolithic kernel) is not very modular.  Many of these problems 
simply can't occur when the only way system processes can communicate is 
through a tightly defined protocol.  See my earlier example of sshd and 
httpd: one can only kill the other if the kernel allows it (ie, if there 
is a bug in the kernel).

> is a pointer bug in one piece of code causing a problem at some other
> random place in the system.  This certainly is useful, but I am not
> convinced it is worth the tradeoff.

I absolutely am.  I am convinced we'll see much more rapid system 
development under a well planned microkernel system.

> The linux kernel seems pretty good at staying up.  So does BSD.  If your

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.

> memory management module blows up, what is the rest of the system
> supposed to do on a microkernel system.  Microkernels don't
> automatically make things more stable, they do make it somewhat easier
> and clearer to make sure that one piece doesn't mess up another.  Of
> course if one piece is critical to the operation of the system as a
> whole, it has to be right no matter what, microkernel or not.

There are no absolutes but in a microkernel design there are less ways to 
kill the critical system (since less lines of code have the ability to 
kill it).

> Unix design hasn't given up yet.  It is evolving though.  We have memory

I think *nix is great.  It is the best OS out there in common use today. 
But it is showing its age.  Plan 9 is a great example of how unix would 
have been if it had been started in the 1990s.  I reiterate, if we have 
not advanced beyond the current crop of OSes in 20 years I think we've 
made a big mistake.  Most of the OSes on the horizon (experimental or 
otherwise) draw conceptually from unix while leaving behind much of the 
baggage.

>> [1] Now was it 2.4.15 where a filesystem patch broke the buffer-cache
>> resulting in filesystem corruption if you did not properly unmount before
>> system halt?  Such a problem cannot occur between (for example) the
>> filesystem code and buffer-cache in a microkernel any post than sshd can
>> take down your web server now (ie, if it manages to do it, it is only
>> because the system allowed the behaviour).
>
> A microkernel can have a buggy FS module too.  What is the difference?

But this is precisely the problem.  The bug was not in the FS, it was in 
the buffer-cache but it damaged the filesystem.  In a microkernel based 
system the communication protocol between the FS service and the 
buffer-cache service would not allow the damage to occur.  Indeed if it 
did the protocol itself would be at fault.

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