by Kevin O'Connor

I think I'll preface my remarks just by saying that the single
example of a capability that I kept in my head as I read this
paper was that of an open file table -- the kind a kernel keeps track of
on behalf of a particular process. If the process wants to write to
a file, it presents its reference to that file via a certain
procedure...at which point the kernel can check whether this process has
the appropriate rights to perform that procedure on that file. That's not
news to you, but it just helped me keep this paper in perspective. And my
only hope is that this example is general enough that it doesn't somehow
restrict my understanding of capabilities in Hydra, since I filtered much
of the Hydra paper through it.

That said, I think Hydra's major weakness is something which is not
mentioned in the paper: performance. In the spirit of Wulf et al, I would
agree that "flexibility and protection are closely related, but not
inversely proportional." But I would then have to add that protection and
*performance* are also closely related, and quite likely are inversely
proportional.

Here are a few reasons why I think so. I can't argue much with someone
who says that Hydra provides exceptional protection mechanisms to
higher-level users, so I wouldn't claim that protection was its major
weakness (rather protection is its major accomplishment). But there's
always a give and take involved when you make part of your system
extremely good at one thing, and it usually means that you've had to
compromise on some other aspect of your system. Take an algorithm, for
example: do you want a fast algorithm or a small algorithm? You can
almost never have the best of both worlds.

An even more apropos example is travel: Do you want to get there quickly,
or get there safely? If you value quickly, you might be tempted to try
out the latest rocket-propelled-whatever even tho it's not too safe. Or,
if you're like the Hydra folks, you're top priority is to get there safely
even tho that means you have to walk all the way there.

That's sort of a theoretical argument about what the major weakness likely
is, and here's concrete evidence. Most people will complain that mere
context switches from process to process are exceedingly costly to system
performance. Here the kernel has to intercede and do the housekeeping of
taking one process off the cpu and putting a new one on. Yet Hydra has
made the kernel's job even more costly by mandating (for reasons of
protection) what to me looks like context switching on the *procedure*
level. That's probably exaggerated, but every time a procedure is called
in the Hydra system, the kernel must crosscheck the rights of the
capabilities provided in parameters with the rights needed to use this
procedure. Only the kernel can perform these checks (in order to preserve
the protection scheme) and the process must halt until the kernel
completes and then finally passes control back to the just-called
procedure.

Now, in writing this, I realize that in my own example of an open file
table this is probably the best way to do things, at least in conjunction
with an access list. The first file request checks the rights to this
file in an access list and, if ok, associates a capability with the
requesting process for the lifetime of the process.

But this last statement suggests still more performance issues for
the system which must keep track of all these capabilities. What if the
rights change suddenly and certain process' rights to a capability must
be revoked or altered? For example, a file that IS owned by someone
(ie, we've used Hydra to create the notion of ownership, even if it is not
fundamental to Hydra's design) is in use by another user when suddenly the
owner wants to make this file unreadable to all but himself. It is not
clear to me how Hydra would facilitate this, but it seems as tho it would
be very costly.