OT: Can We Make OSes Reliable and Secure

Robert Brockway rbrockway-wgAaPJgzrDxH4x6Dk/4f9A at public.gmane.org
Fri Jun 2 22:57:19 UTC 2006


On Fri, 2 Jun 2006, D. Hugh Redelmeier wrote:

[Many excellent points made, but snipped for brevity].

> - Do the programs (like ones written in C) need extra-lingual
>  enforcement to make them safe to their neighbours (eg. separate
>  address spaces)?  We in the UNIX world assume this, but it wasn't
>  true in the Burroughs machines (from the B5000 of ~1960 on).  It

Yes this is an interesting design.  Personally I still prefer the idea of 
enforcing seperate through seperate addresses spaces.

> Right.  That should be true in a monolithic kernel too.  I think that

Certainly.  But are there any examples of monolithic kernels where it is 
true?  I don't know of any.  There may be some where it is partly true. 
The tendency seems to be to create spagetti code within a monolithc 
kernel.

Mind you, a monolith kernel is still susceptible to malicious code as any 
protocol designed would in essence be "self enforced" by the subsystems. 
In a microkernel it is possible to truly enforce the protocol (assuming 
seperate address spaces again).

> various lint-like tools that are being brought to bear on the kernel
> are trying to discover / enforce protocols.  How much better it would
> be if those protocols were declared.

Definitely.  With such an arrangement we would certainly be enjoying many 
of the benefits associated with microkernels.

> UNIX (including Linux) is mostly "good enough" so it is hard to
> replace it, even with something better.  Plan 9 didn't manage to.
> Inferno didn't.  (It might be possible to replace it with something
> worse, like MS Windows :-)

The "good enough" argument is spot on.  I just hope we break this mold in 
the future (and I think we will).  I very much doubt todays common OSes 
will be good enough in 2025.

> I like the ideas of Plan 9 a lot.  And I've had plenty of opportunity
> to try it.  I've only once gotten so far as to try installing it on a
> machine (I gave up at the first sign of trouble).  Why?  I've got a
> tremendous investment in UNIX that I doubt is worth giving up.  The

You don't actually have to give it up.  There is no problem with running 
part or all of UNIX (or something that looks and tastes identical) along 
side other OSes in a properly build microkernel system.  It's just about 
plugging in the right subsystem (and indeed many moderm OSes can already 
do this much).

To give you a couple of examples:

1. MkLinux.  An early Linux supported by Apple.  It can Linux on top of a 
microkernel.  According to Wikipedia the project is alive - there you go, 
I thought it was dead.

2. Some mainframes interact with the world by emulating UNIX - but only as 
much or as little as they need.  A very elegant design.

You could be running an microkernel right now and having a Linux 
subsystem runnig on top (as a set of services in userspace) along with a 
FreeBSD subsystem and a Plan9 subsystem.  In the end it is all just data.

IMHO our current attempts at virtualisation are a result of inability of 
underlying OS to virtualise properly.  I believe in the future the 
virtualisation will be seemless with the OS - I mean more than it is with 
any OS now - it will just be that people won't think of virtualisation as 
something seperate from the OS, it'll just be about plugging in the 
required subsystems and running what you need to run.  Each subsystem can 
see as much or as little of other subsystems as is needed.  This could all 
be governed by a powerful ACL system.

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





More information about the Legacy mailing list