Attenuation
Problem
  • Some powerful authority P has been created. A weaker form F, which is a strict subset, is desired. The implementation of P cannot be modified for reasons such as:
    • Expansion of a TCB,
    • An unacceptable risk of introducing bugs in code implementing P,
    • Death or other resistance by implementation owner,
    • Proprietary code,
    • Secret code,
    • Restrictions whose nature must be withheld from owner of P.
  • Unmodifiable legacy code exists which is designed to invoke P, but whose access must be limited.
    Solution
    Write new code designed to invoke P, and respond as P but only for those actions to be allowed in the lesser authority. Reinstall system with a new capability F that invokes an object that obeys that new code. Substitute F for P in those places where the lesser authority suffices.
    Super Patterns
    Wrapping
    Ramifications
    The attenuator may be highly dependent on the format of the interface, and partly on the semantics of the interface. Alternatively if the restriction is merely the elimination of certain methods, then a standard parameterized attenuator may be used.

    In Keykos if the test is on the input, the attenuator can choose to reject the request and respond as P would for invalid requests. If the request is OK then the attenuator can pass the resume key for the requestor on to P and the response need not travel back thru the attenuator. If the test involves the reply, then the attenuator can invoke P and condition the reply to the requestor on both the request and P’s response.

    If the legacy code wields a rescindable version of P and the rescindable logic is prepared for upgrade, then the restriction can be put in place while the system remains in service and no reinstallation is needed.

    An attenuated capability can impose novel restrictions on the actions possible or the information available thru a capability. For instance I can attenuate a read-only access to a key accessed collection to only access records with keys ending in “ski”, or zip codes for southern states. I can do this polymorphically with a small amount of code and probably rather good performance contrasted alternative solutions to such problems.

    In Keykos I can even attenuate a segment to provide access to even numbered bytes but not odd numbered bytes. To do this I must have notification of changes to the original segment. The segment keeper of the original segment is in a position to do this, but most current keepers do not.

    The Keykos kernel provides means for attenuating a segment my making a weaker segment that is a:

    • read-only version of the original,
    • contiguous subsegment of the original,
    • Segment Transforms
    Here a segment is a region of virtual memory (RAM) which is a contiguous portion of an address space. This is a particular Keykos trick although special cases are seen in some other systems.
    Problem
    Two layouts of RAM are in common use for some particular sort of information. This variation may be due to legacy or unavoidable tradeoffs. An example is pixels in a display buffer; it is necessary to support a variety of pixel formats.
    Solution
    Change notification is a pattern with special significance to:
    Ramifications
    o
    Change Notification (Lamport cells?)
    Problem
    A program acts when it stores a value into a variable. Sometimes it is necessary to take some additional prompt action when this variable is modified. It may be that the program that stores cannot be coordinated with the program that is responsible for the action:
    • Perhaps the program that stores cannot afford to include tests for performance reasons. For instance it is used in most contexts where no such notification is needed.
    • Perhaps the storing program is being debugged and the responding program is the debugger.
    Sometimes it is necessary to deliver the signal before the store takes effect (Prior notification) and sometimes it is merely necessary to schedule a process subsequent to the store. Some hardware stops the program upon storing into predefined addresses after the storage modification has commenced but before any subsequent instructions have been executed.
    Solution
    If efficiency is paramount it would seem that hardware support is necessary. Page maps can be made read-only for multiple regions of a segment. Pages may be too coarse to be efficient. Some hardware provides additional facilities to watch for modifications to a few areas less than a page. Often such functions are not made available outside the kernel. If efficiency is not paramount and the program is interpreted or is compiled late, then tests can be applied by the interpreter without modifying the program proper.
    Ramifications
    Applications
    COW
    This function is necessary for COW (Copy on Write). The notification must be prompt lest the value about to be replaced by the store be forever lost. The Unix systems of which I am aware provides this function in the kernel and provides it to the COW logic. It will not provide notification to others.
    Dirty Pages
    The kernel is instructed to allow a process read-write access to a page. The kernel suspects that the process will not store into the page for significant periods of time. The kernel may choose to make the page read-only and make a disk copy of the page anticipating that the most likely next event for that page is the usurpation of its frame for other purposes. If the kernel is wrong and the process indeed stores into the page, the kernel must learn of the fact so as to know that the disk copy must not be used.
    Logical Variables
    This facility is related to Logical Variables which are used in languages such as Prolog. Computations can await assignment of a variable; computations unknown to the program producing the value for that variable.
    end