Re: HURDNG : Which type of OS design could we have to think nowadays ?

[Jonathan S. Shapiro]

On Tue, 2006-08-08 at 08:21 +0200, Marcus Brinkmann wrote:
> At Tue, 08 Aug 2006 00:28:33 +0200,
> "Ernst Rohlicek jun." <address@hidden> wrote:
> > Persistence: Well, I'm not sure whether orthogonal persistence (in my 
> > interpretation this is quite similar to hiberation / suspend to disk) is 
> > really required - better: what it's benefits in a general-purpose OS for 
> > non-embedded CPUs are...
> > 
> > After all you can still store your caps on disk, if you would like to.
> 
> You can, but if you do not save all the state, but only part of it,
> you face the non-trivial question which state to save and how to
> reconstruct the state that you don't safe (if it needs to be
> reconstructed).  Clearly most of the state in your machine at any
> given time is junk.  If you tell me which 90% of it is junk, I'd be
> very happy to drop the rest.

The problem is actually much deeper than this: if persistence is not
transactional, then it is very difficult to do certain things correctly.
This is true even without capabilities, but even more so when you have a
capability system. Orthogonal persistence turns out to be the most
efficient way to achieve this, and (subjectively) it's a very pleasant
feature to have.


Here is the problem:

Because capabilities are the basis of authority in a system, stores to
capability slots need to be transacted. Otherwise, you can get into a
situation like this:

  A stores cap C to object X
  B reads cap C from object X
  B performs some action that is only legal if be holds cap C.
  The result of B's action is saved.
  The system crashes without recording the store of cap C.

In this scenario, the system is in an inconsistent state after reboot,
and it is very difficult (mathematically) to say anything about the
system security state.

There is an analogous problem in the UNIX login program: you would
like /etc/passwd and /etc/shadow updates to be transacted, but they are
not. There are many other examples in UNIX, and many many of these have
been the source of security exploits at various times. Experience shows
that they are extremely hard to get right, and it would be nice if
programmers did not have to worry about them.

The best solution is to have a transacted store, and the question is
now: what should the granularity of the transactions be?

[Marcus wrote:]
>So, to answer this question, we need to look at all the state and need
> to be able to label it with "save this" or "don't save this".

Because there is a security issue here, untrusted code (i.e. the
majority of application code) actually cannot be relied on to make this
decision unless the system does a whole lot of expensive causality
tracking.

There seem to be two common solutions to this problem:

1. Transactions are managed by processes individually, and the system
records interprocess causal dependencies by remembering messages. This
is incredibly hard to do right, can lead to cascading rollback, and has
high overhead in all the implementations I know about.

2. Transactions are orthogonal and systemwide. The implementation is
intimately connected to the paging subsystem and can use that to lower
overhead. No tracing of causality is required. This solution is very low
overhead, but it requires that the OS data structures have been designed
to support it. This is the EROS/Coyotos approach.


For a while, we considered removing persistence in Coyotos. Eventually
we figured out that we were being silly. Once you can page kernel
objects (which we need to do anyway just for paging) the marginal
complexity of orthogonal persistence just isn't very big.



shap