Re: Changing from L4 to something else...

[Jonathan S. Shapiro]

On Fri, 2005-10-28 at 04:40 +0200, Yoshinori K. Okuji wrote:
> The recent debate in this list makes me very afraid of a possibility of 
> extreme cost which never finish in a reasonable amount of time or human 
> resource... What makes me scared the most is security paranoia (I'm sorry 
> for my wording).

The fear about security paranoia, I think, is mostly because security
involves new and unfamiliar ideas. That much, I think, we can solve
fairly quickly by driving the issues down to concrete design patterns
that people can work with. People think security is hard, but our
experience teaching people how to deal with this on EROS has been that

  (a) getting EROS right really WAS hard, but

  (b) given EROS as a substrate, once we explain the secure idiom
      for doing something the third time, a light bulb goes off
      and the client says something like "Oh. Right. That's perfectly
      obviously a better and simpler way to do it."

A few things definitely were a nuisance, but most of these will be
better in Coyotos (mainly because these were the things that caused us
to make the changes that *led* to Coyotos).

The completion concern is valid and it is justified by the Hurd history.
The following items may relieve *some* of your concern:


1. The KeyNIX emulator described in

        http://www.cis.upenn.edu/~KeyKOS/NanoKernel/NanoKernel.html

took one developer only six months to build. Alan Bomberger, who built
it, absolutely *hated* UNIX, and he probably spent two of those months
complaining about how much UNIX sucks. My personal favorite was his "bug
for bug compatible" line.

I do not suggest that KeyNIX should be the end, but it is a reasonable
beginning. Unfortunately, it would need to be done from scratch, because
KeyNIX was never released. It was binary compatible, and it was fast
enough.

2. The big design issue is really the driver issue, and this needs to be
solved in Hurd regardless. By combining efforts, this is an area where
we can actually reduce total effort.

3. The security features that we have been talking about in EROS exist
already. They will need to be recompiled. It is only the kernel that is
going through a major reconstruction. What we need to do is properly
document them and provide some examples of how to use them effectively.

4. If you look back at my industrial history, you will see that I have a
*perfect* track record for delivery on time and within budget. This
hasn't been a goal in research, but I haven't forgotten how. FLOSS is a
bit different from traditional development, but my stuff has a way of
getting shipped.

The question isn't whether we can make this effort converge. The
question is whether people are actually willing to do the work. That
part has nothing to do with security or kernel choice. It has to do with
motivation and drive.

This is why I have been asking about what is compelling to the **end
user**. If we are building something cool, people will want to
participate to make it happen.


> Some people tend to desiring 100% security, but it is simply
> impossible or not feasible in reality.

I agree completely.

> Security is a matter of a degree. The question is not if it is secure or not, 
> but how much it is secure.

I agree with this also. But in the absence of strong security
architecture, the only achievable degree of security is ZERO. This is
how you get Windows, Linux, OS-X, and (sorry) current Hurd.

shap