"Operating System Structures to Support Security and Reliable Software", herein called "the paper", is by Theodore A. Linden, Institute for Computer Science and Technology, National Bureau of Standards, Washington D.C. 20234. Published in ACM Computing Surveys, Volume 8, Number 4, December 1976, pp. 409-445.

This paper is a high-density survey of some of the issues that motivate Gnosis. It gives a framework in which systems such as Gnosis can be described. The paper induces many architectural attributes of an operating from the requirements and by abstraction from modern operating systems. Since this structure is very much like Gnosis it invites comparisons in the areas wherein Gnosis differs.

Section 6.2 of the paper observes that these systems have only interpretive access to shared data if the hardware lacks the capability features. In Gnosis, however, we use the standard 370 hardware {which has not hitherto been called capability hardware} but we have direct access to shared data. The data, not a copy of it, is in your memory. Shared data is modified at the instant the store instruction is finished.

We will induce more detail about the "standard" capability hardware and then describe how Gnosis mimics that hardware with the 370 architecture.

In some "standard" capability hardware there are a few, say 16, capability registers each able to hold a capability to a segment. Instructions that reference memory have a four bit field indicating which of these registers hold the capability to the segment to be used. These capability registers may be loaded and stored freely in parts of memory somehow designated to hold capabilities.

The simplest mapping of this into Gnosis is to take an LSS=5 segment as the top node of the memory tree {(p1,memtree)} of a domain. The 16 slots of this segment node correspond directly with 16 segment capability registers above.

Instead of the 4 bit field in the instruction, bits 8:11 of the virtual address select which of the 16 segments are used in a particular memory reference. See (p1,gss) for more flexible arrangements.

The loading and storing of these capability registers is accomplished in Gnosis by fetching and storing into the LSS=5 node of the memory tree. This action is interpretive as are the page faults that ensue when the newly valid virtual addresses are first used. Subsequent access to the data is at normal instruction speeds because the pages {and frequently page tables} are shared.

Other 370 operating systems share either only on 1M segments, 64K segments or pages. Gnosis shares nodes in memory trees and shares segment tables, page tables and pages whenever possible.

Section 7.4 paragraph 3 suggests that perhaps there should be some enforcement of a policy that capabilities that are held for "relative long periods of time" be kept only in directories.

We have not planned such a policy and indeed it seems to contradict the building of abstract data objects from capabilities. Such objects must have imbedded capabilities and hopefully such objects can be long lasting.

The phrase "relative long periods of time" seems to indicate some sort of compromise. I am not sure what the trade-offs are in this compromise.

In the next subparagraph it is suggested that some capabilities be placed on the stack in such a way that copies cannot be made of them. I think that this is to solve some problems addressed in (p3,confine). Several years ago the Gnosis design contemplated uncopyable keys (for other reasons). They seemed to cause many problems to the design of user programs.

We have resisted, so far, the temptation to make special rules for programs in some environments over others. We have tried to hold to the idea that the only distinction between programs (other than the kernel) is what keys they hold.

We think that will ultimately simplify proofs about the system.

I think that the motivation for uncopyable capabilities on the stack is to prevent access to an object subsequent to the termination of that activation record. This might be desired because secrets may be placed in the object subsequent to the call and that information should be available to might have kept a copy of the key. Revocation {(p3,revoke)} is designed to solve that problem.

With regard to interprocess communication channels, we presume that any such are comprised of capabilities held by the communicators. If you don't want them to communicate, don't give them the capabilities.

See (p3,revoke) about the revocation of capabilities.

The only potential problem that I see is the granularity of storage protection, a page.