Re: Restricted storage

[Marcus Brinkmann]

At Mon, 29 May 2006 11:16:10 +0200,
Bas Wijnen <address@hidden> wrote:
> So far, there have been two examples where restricted storage seemed needed:
> Running a competition, and ping.

Just for the record: I think that the ping example has not been very
enlightening, mostly because the whole subsystem it lives in is
underspecified at this point.  This is certainly because neither Neal
nor I (in particular) are experts in network technology, so we never
focussed our attention on those issues.  This means that at this point
I can not even tell what the right objectives are in that area, not
even talk about implementation details.  However, I am going to play
along by accepting the various assumptions made for the sake of
discussion.

> I'm particularly interested in ping at the moment.  We can say that we'll use
> the "limited number of simultaneous uses per user" approach, but we would
> really prefer to have no limits on this.  So in that case we will need
> read-only storage.  Marcus stated that because the network driver is provided
> by the system, it can simply take some user storage and give it back later.
> In other words, the system can choose to use opaque (or read-only) storage,
> even if it doesn't allow this functionality to normal programs.
> 
> This last statement is of course true.  However, the one before it may not be.
> Assuming that we have a good driver framework, it is very well possible that I
> plug in my own network card on a usb port, which connects the machine to a
> couple of other computers.  Suppose this happens on a university, and some
> students arrange this setup so they can all use those other computers.  Since
> I'm behind the terminal with the network card, I own the usb bus and provide a
> network driver for my card.  The other students will tell their shell that
> they want to trust my driver and use it for communicating with the other
> machines (not a lot of trust is needed for that, but they must be explicit
> about using my driver, of course).
> 
> In that case, my driver will be unable to use restricted storage if the system
> doesn't provide that functionality to "normal" programs.  So then there are a
> few options:

> - My driver doesn't support ping, or only in a limited way, so it uses
>   "constant" storage (where this "constant" is a function of the number of
>   users on the machine).
> - My driver fully supports ping, and is vulnerable to DoS by its users (which
>   are all trusted (in a real-life social way) students, so this might be
>   acceptable).
> 
> In both cases though, I cannot use the "normal" network driver, because that
> uses (at least) read-only storage, which is unavailable to this one.  So there
> is a need for two different driver programs depending on if it is system
> installed or not.  This is unfortunate.

Given the assumptions you are making, what you derive seems
approximately correct.  However, there is a reason for the difference:
The two cases have very different characteristics.  While in the
system driver case, the agent implementing the storage service is
essentially identical to the agent implementing the network service,
in the user driver case they are separate.  This is fundamentally what
causes the issue.

If the other users would run completely on storage provided by you,
then again you could use the same approach as the system service.

There are at least two consequences from this: First, the other users
do not get any guarantees about what you do with their data.
Supposedly you send it over the network, but you could also keep a log
of their data, and/or use the memory to increase your own quota.  Of
course the system driver could do the same, however, the system
already is in a position to do that anyway.  On the other hand, the
storage you get is not durable: The users could revoke it at any time.
Thus, you can _not_ "lock" the memory (to prevent its deallocation),
and need to be extra careful when handling it.  The system is in a
position where it could "lock" those pages.

I think that these differences are big enough to justify two different
cases.  You may reasonably disagree, however, I would point out that
even if you give a restricted storage functionality to users, you
would only have eliminated one of the three differences.  Differences
in inspection/misuse and durability would still exist, and very
difficult (impossible?) to eliminate safely.

Thanks,
Marcus