On Tue, 2006-08-08 at 08:21 +0200, Marcus Brinkmann wrote: > At Tue, 08 Aug 2006 00:28:33 +0200, > "Ernst Rohlicek jun." <[EMAIL PROTECTED]> wrote: > > Persistence: Well, I'm not sure whether orthogonal persistence (in my > > interpretation this is quite similar to hiberation / suspend to disk) is > > really required - better: what it's benefits in a general-purpose OS for > > non-embedded CPUs are... > > > > After all you can still store your caps on disk, if you would like to. > > You can, but if you do not save all the state, but only part of it, > you face the non-trivial question which state to save and how to > reconstruct the state that you don't safe (if it needs to be > reconstructed). Clearly most of the state in your machine at any > given time is junk. If you tell me which 90% of it is junk, I'd be > very happy to drop the rest.
The problem is actually much deeper than this: if persistence is not transactional, then it is very difficult to do certain things correctly. This is true even without capabilities, but even more so when you have a capability system. Orthogonal persistence turns out to be the most efficient way to achieve this, and (subjectively) it's a very pleasant feature to have. Here is the problem: Because capabilities are the basis of authority in a system, stores to capability slots need to be transacted. Otherwise, you can get into a situation like this: A stores cap C to object X B reads cap C from object X B performs some action that is only legal if be holds cap C. The result of B's action is saved. The system crashes without recording the store of cap C. In this scenario, the system is in an inconsistent state after reboot, and it is very difficult (mathematically) to say anything about the system security state. There is an analogous problem in the UNIX login program: you would like /etc/passwd and /etc/shadow updates to be transacted, but they are not. There are many other examples in UNIX, and many many of these have been the source of security exploits at various times. Experience shows that they are extremely hard to get right, and it would be nice if programmers did not have to worry about them. The best solution is to have a transacted store, and the question is now: what should the granularity of the transactions be? [Marcus wrote:] >So, to answer this question, we need to look at all the state and need > to be able to label it with "save this" or "don't save this". Because there is a security issue here, untrusted code (i.e. the majority of application code) actually cannot be relied on to make this decision unless the system does a whole lot of expensive causality tracking. There seem to be two common solutions to this problem: 1. Transactions are managed by processes individually, and the system records interprocess causal dependencies by remembering messages. This is incredibly hard to do right, can lead to cascading rollback, and has high overhead in all the implementations I know about. 2. Transactions are orthogonal and systemwide. The implementation is intimately connected to the paging subsystem and can use that to lower overhead. No tracing of causality is required. This solution is very low overhead, but it requires that the OS data structures have been designed to support it. This is the EROS/Coyotos approach. For a while, we considered removing persistence in Coyotos. Eventually we figured out that we were being silly. Once you can page kernel objects (which we need to do anyway just for paging) the marginal complexity of orthogonal persistence just isn't very big. shap _______________________________________________ L4-hurd mailing list [email protected] http://lists.gnu.org/mailman/listinfo/l4-hurd
