At Mon, 29 May 2006 11:16:10 +0200, Bas Wijnen <[EMAIL PROTECTED]> 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 _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
