Split Capabilities: Making Capabilities Scale

[Jonathan S. Shapiro]

> > > I love a hostile audience...
> >
> > Oh dear. I hope not hostile.
>
> Of course not, although I've had hostile (mostly inside HP), and I've
> enjoyed that, too.

Well, if it will make you feel more comfortable, I suppose I could
gratuitously insult you once in a while. :-) Ahh. I have it. Your father
smelt of elderberries! There. Your quota of E-speak hostility for the week
is now reached. You are now free to send SIGKILL to any further hostile
parties. :-)

> The process the agent runs in is not persistent, nor is its execution
state.
> E-speak binds the capabilities to the agent's protection domain, not its
> executable image.  The agent's protection domain can be persistent, so
that
> its security environment persists across restarts.  The first thing an
agent
> does when starting is attach to its protection domain.

I think that this has added a layer of indirection, and also some confusion
on my part. I understand how to make the domain persistent independent of
the process, and I think this is quite sensible. My question is this: when
the process goes to "attach" to a protection domain, how is it determined
that this process has the right to use the authority captured by this
protection domain?

There is an interesting middle ground of persistence, which is to keep a
registry of (domain, binary) pairs for processes that should be restarted,
but live with the fact that the programs must reinitialize. This is perhaps
more useful in your model than in ours.

> ... capabilities are definitely not associated with an
> executable image and not necessarily attached to an instance.  Instead,
they
> are attached to principals, each principal having its own protection
domain....
> Hence, your wallet has a different capability than mine, but I can have
two
> wallets controlled by the same capability.

Once you fall back on principals for this it's all over as far as security
is concerned. It's definitely better than what we have in commodity
deployment today, but not good enough for some of the problems I want to
solve.

My wallet can have different capabilities than yours, but can I have two
wallets, both mine, to two different accounts that hold distinct
capabilities?

> Hmmm, strange.  HP is promising 4 9s (99.99%) uptime this year and 5 9s
next
> year.  That's only 5 minutes a year of unscheduled down time.

When you get to 6.5 9s you are reaching KeyKOS reliability, and I expect
that EROS may prove to do better. E and E-speak are principally limited by
the reliability of their underlying OS. This means that their reliability
sucks but its not their fault.

> Reliability
> is the main reason Amazon gave for replacing its Sun servers with HP
> machines.  Probably, their environment is more controlled than the one you
> work in.  I know my HP-UX desktop machine only goes down if there's a
power
> failure, but again, I don't know enough about operating systems to be
> dangerous.

Part of our problem at Penn was that we bought into the HP clustering
technology, which wasn't soup yet. Various people were heard to say that we
had a new appreciation of the term "cluster fucked". I think the real issue
was long-term administrative neglect. Clusters are quite hard to upgrade
consistently in that sort of environment, and I'm not convinced that it was
done correctly. Independently, HP was unwilling to disclose enough to let us
build drivers and such for those machines, so we didn't have a whole lot of
incentive to keep them running well.

We should probably pick up the reliability thread in the eros-arch list if
it is of interest to you. It's kind of off topic here.


shap