[coyotos-dev] Reasons for persistence

Jonathan S. Shapiro shap at eros-os.com
Mon Jun 4 14:01:25 EDT 2007

On Mon, 2007-06-04 at 18:32 +0200, Pierre THIERRY wrote:
> I recently co-authored a paper on persistence, and it occurred to us
> that orthogonal persistence is a great strategy towards hardware failure
> tolerance.
> So I wondered: what are the reasons that made you choose to make Coyotos
> persistent? IIRC, one of them was that it makes the system simpler and
> in particular simplifies reasoning on security.

Perhaps one of the KeyKOS people will chime in here as well.

As I understand it, GNOSIS/KeyKOS adopted checkpoint/restart as a way to
avoid the "secure restart" argument. Problem: establishing that you have
successfully downgraded from "system high" to the correct initial
security state during system boot is very hard (roughly as hard as
showing that the system is secure once booted). If you can instead argue
that you have simply reloaded a previous known-good state, life gets
much easier. A side benefit is recovery and such.

In Coyotos, I initially thought to take persistence out, because it
complicates some scaling issues. Basically, any place where you have two
pointers meeting at an object, as in:

    P1 -> O <- P2

You need a way to record the rendevous to ensure that P2 gets reloaded
into the correct situation. If you instead have

    P1 -> O -> P2

You can rely on pointer chasing to find P2. This means that persistence
and demultiplexing are hard to do at the same time.

I also thought that removing it would simplify a bunch of other stuff.

Turns out that I was completely wrong. Once you have object paging to
the swap area, you have already done the overwhelming majority of the
work needed to support full checkpoint-style persistence. You just need
to make sure that you use a properly abstracted object identifier name
space (which KeyKOS had done, and we inherited).

And yes, it definitely simplifies security reasoning. If you do not save
and restore consistent cuts of the system state, you are effectively
failing to capture the results of the operational "steps" that
constitute the underlying security state induction. This is why the
"secure restart" argument is so hard.

Any of this help?  Hope you cited our stuff!


More information about the coyotos-dev mailing list