OT: Can We Make OSes Reliable and Secure

[Lennart Sorensen]

On Fri, Jun 02, 2006 at 04:44:00PM -0400, Robert Brockway wrote:
> 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.

Only redhat kept resisting the change.  They dragged it out for their
users, everyone else just switched and was happy.  Alan Cox kept using
the old VM in his patches and redhat used that for months before Alan
finally accepted the new VM was the way to go.

> 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).
> 
> I absolutely am.  I am convinced we'll see much more rapid system 
> development under a well planned microkernel system.

Then what took Hurd so long?

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

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

Well the unix user space is excelent.  Little tools (modular design
after all) that do one thing well, working together is great.  Of course
there is no reason a microkernel based system couldn't use the same user
space, and work great.

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

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.

Len Sorensen
--
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