Jim Shearers review of Sharing and Protection in a Single-Address-Space Operating System.

From: shearerje_at_comcast.net
Date: Wed Jan 14 2004 - 13:21:16 PST

  • Next message: Chuck Reeves: "Sharing and Protection in a Single Address Space Operating System"

    Wow! There is a lot to digest in this paper. The basic concept of using a single global flat address space is fairly simple, but when the paper delves into the implications for protection, resource allocation, linking and loading, and temporal issues associated with references, the paper gets quite complex.
    The proposed operating system level protection scheme is applied at a fairly granular segment level (granular because segments are not a fixed size and can be quite large) but does not preclude applications building finer grained boundaries within their protection domains. The actual OS protection mechanism is a combination of capability lists associated with protection domains and access control lists associated with resources. Entries on these lists include some kind of encrypted hash mechanism (cryptographic authentication) to prevent forging and, as a byproduct, to support capability revocation. “Portals” are a specific instance of this protection mechanism that, beyond just constraining access to the domain, also specify specific functions that can be executed within the domain. I would be interested in learning more about the life cycle of the encryption keys used in this authentication.
    The linking and loading discussion seemed to leave some loose ends. The presented concept is that, once linked, a given module continues to reside at the same address location every time it runs. Does this mean that when I purchase a new application for my computer I must re-link the object files (rather than just load the executable) so that its address mapping is correct for my machine? The discussion about resource management and reclamation discussed this (I like the idea of resource groups) but didn’t satisfy me that there are not still serious address space allocation, fragmentation and memory leak issues. The section on Virtual Contiguity, for example, seemed to brush off these issues by demanding ever more memory. I was further lost by the assertion “Dangling capabilities are detectable because they contain a randomized 64-bit check field.” How is the check field used to perform the detection? These issues become more pronounced in integrated software environments (as discussed in the Boeing e
    xample) and in environments with a changing user community (like a campus computer network).
    I kind of glazed-over in the discussion of implementing the prototype on the Mack kernel except for the part about persistence and recovery. This has been a major crisis on every long duration product I’ve ever worked on, and I was pleased to see it raised as an issue even if no solution was presented. The “epoch” concept was thought provoking and should be explored further.
    In conclusion, I liked the protection and data sharing concepts, but was horrified by what I perceive as a very leaky resource management strategy.


  • Next message: Chuck Reeves: "Sharing and Protection in a Single Address Space Operating System"

    This archive was generated by hypermail 2.1.6 : Wed Jan 14 2004 - 13:21:22 PST