design goals vs mechanisms (was: Re: Let's do some coding :-)

[Marcus Brinkmann]

At Wed, 26 Oct 2005 21:32:14 +0200,
Bas Wijnen <address@hidden> wrote:
> - security
> - capabilities
> - persistence
> - real time

> Marcus: is this the type of input you wanted?

Almost.  I have a similar list, but I am not sure it is attacking the
issue at the right angle.  Let me explain.

Security is definitely a possible goal, although (without further
specification) a very vague one.  For example, you say you want to run
possibly hostile code while containing its negative effects, ie impose
certain limits on what it can do: A video codec can read a certain
file, it can write to a certain display buffer, and it can consume so
and so much CPU time and memory.  In other words, you want
confinement.  That's a real goal, too.  It's more specific than
"security".  The more specific we can be, the more helpful it is in
determining the actual mechanisms we need to implement our goals.

In EROS, confinement can be verified _from within the system_.  IE,
there is a mechanism that allows one process to determine if a process
is confined or not.  This mechanism does not rely on an external
supervisor (or only insofar as the actual confinement mechanism needs
to be externally verified).  So, an even more specific goal than
"support for confinement" would be "support for confinement with
endogenous verification".  This could be one specific security policy
we want our system to support.

Capabilities, are they a goal on their own?  I don't really think so.
They don't provide any intrinsic value.  Instead, they are a mechanism
to implement certain access policies.  These access policies have an
impact on what security models you can implement.  So, I think
capabilities are a mechanism, not a goal.  As far as I know, they are
the only feasible mechanism that allow to implement the above security
mechanisms, if the capability mechanism is carefully designed.  The
proof for the claim that a cap system _can_ support confinement is in
Shap's thesis.  There may be other mechanisms that support such
security policies (Shap can surely comment), but they are probably
obscure.

So, "a protected capability system" would be a mechanism, not a goal.

Is persistence a goal?  This depends on what you want to do.  If you
want to pull the plug from your computer and see the same desktop
before the power outage afterwards, then yes, it seems to be a goal.
However, personally, I don't really have this goal, although it is a
nice bonus.  I described my motivation for looking at persistence in a
different mail ("Hurdish applications for persistence").  The goal
would be to eradicate access control lists from the system, and
preserve the execution context ("session") of a user's processes
across reboots.  You correctly point out that global transparent
persistence is not the only mechanism that supports this goal, there
are also orthogonal persistence schemes, or even some "bootstrapping
methods" that work more like traditional Unix (ie, you recreate the
user session from some on-disk data format).

So, "persistence" would be a mechanism, or a goal.  Some goals, like
eradicating ACLs, strongly suggest persistence as a mechanism.  Again,
security seems to be a primary motivation, but this time we are
talking about a different security policy than above.

Support for real time applications is a proper goal.  Actually, making
real time applications possible at all is a proper goal, independent
of the question if we want to make our code meeting real time
guarantees or not.  You say that you don't want hard real time, but
you want something that I want to describe as "soft real time", ie low
latency responses for certain application classes like multi-media.
This also is a proper goal.

Here are some other goals you can have: Stability, robustness, Small
memory footprint (for embedded applications), Support for legacy
applications...

The point of this mail is to make a distinction between design goals,
and engineering mechanisms to achieve them.  I think it is very
important to separate the two, but we can't make a clear separation:
The design goals dictate the feasible engineering mechanisms.  This is
why Jonathan wants us to come clear, because only by settling on the
design goals we can settle on the feasible mechanisms to achieve them.

I think in the end we will be faced with a dilemma: Either we have to
accept the logical consequences of our stated design goals, which may
be deep.  This includes removing any paradoxes by dropping some in a
set of conflicting design goals.  Or we drop some of our design goals
to open up space for other engineering mechanisms.

What's it gonna be?

Thanks,
Marcus