The fetch key {(p2,fetch)} has a curious status.

The {Old} Trouble with the Fetch Key
It was included to provide a capability symmetrical to the read-only page key.

It was, however, somewhat of a trap -- one might hastily think that a fetch key to a tree of nodes connected by node keys provided read-only access to the slots in the tree. Of course node keys in the first designated node could be gotten by the fetch key holder, whence he could modify the rest of the tree.

Worse, section (p2,fetch) once provided for the transformation of a fetch key into a meter key. This increases the authority of the node by allowing counters in the node to be changed. We have prohibited changing fetch keys into meter or segment keys.

It was yet worse. Even if you can't turn a fetch key into a segment key you could use a fetch key as a memory key {in a slot of a segment node} and perhaps call the segment keeper designated {inadvertently} in the indicated node and end up in a hostile segment keeper holding a node key to the designated node.

Some programs use fetch keys merely as an indication to themselves.
It would be nice to build a segment keeper for a virtual copy {of an original} that had sufficient access to the nodes of the original segment to cause the tree of the virtual copy share those nodes but insufficient access to influence the original.

This could be done by introducing some sort of memory key that allowed fetching memory keys from the designated node and restricting the memory access rights in the operation.

Section (p3,womb) is a valid use of fetch keys.

Implemented changes for fetch keys:

Fetch keys are no longer segmode keys when the lss is 0.

Fetch keys are not able to produce meter and segment keys.

I think that it would be ok to produce segment keys with the no-call bit on.

These are the ideas that led to the creation of the sense key.

This section is a {coordinated} accretion of ideas to fix the fetch key problem {(p1,fetch-fault)} and at the same time provide for efficient signal diodes between worlds.

We would like to invent a new kind of key that could be held in world A to a node in world B such that the key did not provide for signals from world A to world B. Possible definitions of the idea of a Diode:

We say that world A cannot see world B if A's state is uniquely determined by the earlier states of A {and thus does not depend on the state of B}.

I propose a new kind of key, the (_sense) key, with the following properties:

The sense key is to support the reading of information in world B in such a way as not to disturb world B.

The direct actions that a sense key presumably supports is to:
read data from pages when the sense key is used as a segmode key,

allow the sense key holder to make a weakened copy of a key from the designated node.

Accordingly I propose that sense keys not support writing or segment keeper calling when used in memory trees as memory keys. {As if the read-only and no-call bits were on.}

Similarly I propose that the following transformations be performed on the copies of keys made for the holder from the designated node. This transformation is called the (_sense transformation).

Node, Fetch or Sense key -- Sense key to the same node with same databyte but RO and NC bits on

Segment key -- Same key but with no-call and read-only bits on

Page key -- Read only page key to the same page

Data or Miscellaneous key -- Same key

Others -- DK(0) {Sorry about that!}

A call on a sense key would return the databyte from the key.

The utility of sense keys stems from the following fact:
For a set of pages and nodes TS {Top Secret} the following situation will persist if it is once true:

All keys that designate pages and nodes of TS are in nodes of TS and all keys in TS that designate nodes and pages not in TS are sensory {(p2,sensory)} keys.

Design Problem with Sense Keys
There is a problem with sense keys that we have not yet overcome; how does one build synthetic nodes {(p3,synnodes)}?
The problem occurs when a real sense key is used to make a weakened copy of a synthetic node key. The synthetic node key is really a segment key with a keeper {because node keys can be used in memory trees} and the operation makes it no-call. The resulting key cannot serve as a synthetic sense key because the keeper can no longer be called.

This problem seems to me to be an inherent conflict of principles:
The builder of the synthetic node cannot do his thing without putting himself in a position to observe key fetches.

The agency responsible for the key to the node being a sense key rather than a node key is concerned about just such observations {or at least that no report be made to inappropriate places}.

It seems that this problem is similar to the conflict between a segment keeper and an installer of the no-call bit:
The segment keeper might like to provide the illusion of a complete segment but if the segment key holder looks at the segment thru a key with the no-call bit on, the keeper cannot provide that illusion.

This problem was unilaterally decided in favor of the segment holder.

To strengthen the analogy we might well call the segment with an active keeper a synthetic segment. The no-call bit thwarts the keeper's strategies as the sense key thwarts the synthetic node maker, in both cases by ruining the function.

Here is a hint of a solution here but we have not found an entire solution.
If we could convince the kernel that the start key that was the virtual node key, or the keeper of the segment to which the no-call key was being produced led indeed to a discreet domain the interests of the user would be protected.

But who is the kernel to trust?

Ideas from Physics
To grasp for further analogies, the dilemma is whether to build our universe so that Heisenberg's observability principle is true.
Heisenberg based quantum mechanics on an elaboration of the idea that the observer always changes what he observes.

You can't really call a domain without changing it at least momentarily. {Its PSW will be temporarily different.} Even this is too much. Proving that domain will go back to the same state is difficult and insufficient {and is likely to preclude the original use of the synthetic node}.

It can be argued that computers are built of physical things so that it is ultimately impossible to avoid the influence of the observer. For instance a memory bank that is cycling to fetch a word for a top secret user is unavailable to the secret user. Nonetheless I think that it is practical to hide the fetch from the other users.

A similar physical analogy is with Mach's faith that mechanism A cannot affect mechanism B without B affecting A.
Mach thought of space itself as such a mechanism, a viewpoint subsequently required by General Relativity.

The connection here is that the procedure call seems always to affect {change the state of} the callee as well as the caller. The memory reference or sense key fetch, on the other hand, affects the actor without affecting the object.

While it is true that you call the sense key, the fact that the key is discreet depends on the fact that the key is implemented in the kernel.

While it may be true that some domains are the same after a call as before a call, this cannot be established as a consequence of the capabilities they hold.

Perhaps the crux of the situation is that the kernel knows how to arrange the persistence of properties such as (p1,safe).

Perhaps this dilemma can be solved well enough by limiting sense keys as we do domain-tools.

Argument for Sense Keys {September 1981}
It seems that without some mechanism such as the factory {(p2,factory)}, Gnosis will have something akin to the Trojan Horse.
Consider the binder {a component of the loader (p2,loader)}.

A user of PL/I will want to use a binder {which holds the PL/I library} produced by the PL/I expert.

The user will need to add some secret code to the binder. The user must trust the entire logic of the binder to keep this secret from the PL/I expert in the current architecture. Introducing sense keys and modifying some of the creators {including virtual copy makers} means that the implementer of the binder and the PL/I expert need not be trusted to keep the secrets.

While it may be pointed out that these two must be trusted for the correct function of the user's application, this is less critical in some circumstances {DOD, etc.}.

The factory design is currently the only detailed strategy for providing manifestly discreet services. Such services play a major role in the most of scenarios for the use of Gnosis.
The escrow idea {(p3,escrow)} has nothing to contribute here. Indeed we do not know of an efficient way to provide the discreet virtual copy without sense keys.

As of now we have factories but no sense keys. We have not decided how to implement the VCSK without sense keys. There seems to be substantial problems in doing so. We suspect that supernodes may likewise be needed with virtual copy attributes.
In the case of the binder we say that copies of the binder are produced and we would like these copies to be very cheap. The current external specs for the binder call for such copies to include many keys. Some of these keys cease to influence the behavior of a binder subsequent to some binding operations and an intelligent copier would secretly omit such keys from the copy. Other keys will be required. Such keys could be kept available cheaply in a super node if that super node had virtual copy function. If we had such a super node function the dilemma of what keys were required at copy time could be freely ignored.

Perspective as of November 1980
Sense keys provide for some constructs including virtual copy space banks to be done efficiently. Without sense keys it seems that these constructs can be built with factories but only using the more general but potentially much less efficient schemes described in (p2,facade).

shows that a key that designates a node but only does the NODE__COMPARE operation {(p2,node-cmp)} would be useful.

Note that domains are not primitive. This means that programs outside the kernel build domains from nodes. Today there is only one program, the domain creator, that uses the domain tool and thus that is the only program that depends on the particular way domains are built from nodes. The domain keeper trusts space banks that are found to be official.

A unit of operation does not span a disk access.
Since some program exceptions destroy information the PSW can not be backed up. With out the trap code in the domain the only next valid state would be after the domain keeper had accepted the fault information. Thus the fault action would span the disk action of fetching the domain keeper.

Support the hardware facilities {e.g., PER and Monitor instruction}).
This includes supporting the programming techniques anticipated by the machine architects.

Provide for the construction of virtual machines.
It is nearly possible to write a program in Gnosis to provide virtual machines. I presume that channel programs would be interpreted rather than translated. This would be faster sometimes but slower sometimes too.

Gnosis provides nearly enough tools to build virtual machines; but 2K pages and storage keys are features of the hardware that are denied the Gnosis programmer so that virtual machines that he can construct will lack those features.

Since this program would run in a domain it would be at a performance disadvantage to CP.

We would have to provide more direct access to storage and PSW keys. The kernel could perhaps provide access to VMA. This would provide a bigger relative advantage to Gnosis's virtual machines that to CP's virtual machines. That is to say it would decrease the performance disadvantage that CP holds over the program in Gnosis.

See (sie).

This idea is only of theoretical interest {I hope}. It is complementary to sense keys {(p2,sense)} but unlikely to be implemented or of practical use. I think that this construct could be implemented outside of the kernel but I will describe it as being implemented by the kernel.

A black key designates a node. It responds to the alleged key type call with a code to identify itself as a black key. All other order codes provide a return code of 0.

Order codes 16 thru 31 cause a key to be stored in the corresponding slot of the designated node. The key that is stored is a weakened form of the key passed by the black key holder. The weakening is the same as the that performed by the sense key upon fetching a key.

Order codes 0 thru 15 fetch a key from the designated node but again transformed as follows:

Node keys are transformed into black keys to the same node. All other keys are transformed into black keys to a constant {garbage} node to whom no one holds keys other than black keys.

Black keys outside a discreet object to objects in the object are allowed.

The Hydra way of doing things is to have operators and typed things. Operators do their job by having the authority to disassemble certain types of things. In Hydra one hands the operands to an operator.

In Gnosis we typically call the object in order to operate on the object. We select the operation by the order-code that we send to the object. This has the disadvantage that we cannot substitute one transformation for another {in a code-independent manner} without substituting the objects. This doesn't seem too bad.

When we want to create operators that operate on two objects we must resort to something a little like Hydra; we call one of the objects and pass the other object as a parameter. {We hand one operand to the other.} The asymmetry is the only thing that bothers me here.

In the case of segments and their segment keepers we have a dilemma. There will be a growing class of segment keepers and a growing class of conventional segment operations. It seems clear that there is no general way to make all combinations of operations and segment keepers work in an integrated way.

In the Hydra system the problem manifests itself when an old operator gets a new-style object. In the Gnosis system the problem shows up when a newly-defined operation {an extension of old conventions} is applied to a segment with an old segment keeper.

A proposed solution in the Gnosis case is to have a "current conventional segment operations" key that leads to a general program that knows all of the new operations on segments from the outside {given only a segment key}. I am not comfortable with this yet.

There seems to be a basic problem in Gnosis that we have moved about but not solved. I am beginning to believe that the problem is more fundamental than the Gnosis design.

The first version of the problem is that parameter pages must be real. This interferes with the production of synthetic pages.

The second version is that parameter strings must not be at virtual addresses which require the service of a segment keeper.

The root of the justification of these kernel restrictions is that returning from prompt public services must not be delayed by the running of a segment keeper in response to storing into the parameter string.

One of the suggestions has been to put a {real} page key in the domain root to accept the argument on those occasions that the parameter string does exist in real pages.

If such a page holds an argument a bit in the domain root so indicates. before the domain runs again the argument is copied to the indicated parameter string. At this point it is permissible to delay the actor.

This just moves the problem once more. The real page key is still required.

In General
IBM has announced several features for the new large 370s. Some of these incorporate in hardware some of the design principles that Gnosis was based upon. There are these reasons for being concerned with these features for the Gnosis system:
They may be able to enhance applications designed for Gnosis,

These features replace older features required by the current Gnosis kernel.

They may be necessary to run software written to use the new features.

There may be several aspects to such a new feature. Program X may have many PC instructions imbedded in it. Y may intend to build linkage and entry tables. Z may be designed to be invoked by a PC instruction. To satisfy all three at once seems tantamount to running some operating system as a guest. If there are many program like X and few like Y and Z then we can comfortably modify or redo the few and accommodate the many.

The way that these features are included in Gnosis depends partly on which of these reasons apply.

We list some of the features that might bear on the external specifications of the Gnosis kernel.

Some other new features apply to the interface between the Gnosis kernel and the hardware.

Expanded Storage

31 bit real addressing

Channel queuing and automatic path selection

Multi-processing

The main effect of these new features is to allow progression toward much larger hardware and software systems. Most of these features may be used to further the Gnosis style of application design. None of these features are at odds with the Gnosis architecture.

Some delicate code must be written and most modules must be changed.

Multi-processors
The top level design of the kernel is compatible with multi-processing but a number of new locks must be invented and references to them installed. Many of the locks are already there for other purposes.

In addition we must code the actions triggered when a locked lock is met. When a domain acts to modify a domain running on another processor we must somehow arrange for the action to be deferred until the object domain is not running and to hasten its not running.

IBM's DAS {Dual Address Space} Feature
Dual-Address Space {SSAR, etc. - cross-space services}
With this feature a program can access two memory spaces at once {with commands like move to or from secondary space} and indeed to switch between 2**16 address spaces with commands such as SSAR {"set secondary address space number"}.

The net effect is that 2**47 bytes of storage can be addressed without going to privileged code (except, of course, for page faults).

Performance

Control register 14 determines the meaning of these 16 bit address space numbers. The sequence (LCTL 14,14,...; LASP) would be required upon domain switching. This is clearly slower than the LCTL 1,1,... that is now required.

IBM seems to intend that address space numbers be global -- the hardware encourages but does not enforce this.

The tables that define the meaning of the address space numbers are two level tables much like segment and page tables. The same sort of logic that provides for sharing of segment and pages tables can be used to share the address space tables.

Programs that must consult the address spaces of other domains can benefit from this. DDT, OSSIM and CP-SIM are three such now.

Perspective on the PC Command
This feature comes along with dual-address space mode. It provides for calling programs that run in other 24 (31) bit address spaces. The feature is much less general, however, than the Gnosis gate jump.

The PC command is deficient, in our view, because it calls another program in such a way as to grant all authority of the caller to the called program. This is rarely what is wanted in Gnosis. Another fundamental flaw is that there is no switching of control register 14 in this operation which means that caller and called must agree on the meaning of address space numbers. It is as if two domains had to share super address spaces to jump from one to the other.

IBM's architecture has established three different protection principles in one instruction:

You can call whoever you have a start key to {via a 20 bit "slot number" that IBM calls a program number}.

You can load address space numbers if storage keys set values are compatible {anding of boolean vectors},

An access matrix.

Bah!

It is as if IBM recognizes that there are several ideas about how to protect and it should be safe and use them all at once.

Implementing the PC Command for Compatibility
The following scheme allows direct use of the native PC hardware and supports both programs with PCs and PTs without invoking the kernel. Programs that build linkage tables, entry tables and address space tables are supported only thru the mediation of specialized domain programs that interpret such tables for the benefit of the kernel.

A variant type of domain is provided whose address segment slot is supplanted by a "system segment slot". This can be a memory key to a 2**48 byte segment. This segment is the concatenation of 2**16 segments each of 2**32 bytes which constitute the 2**16 address spaces referred to by the semantics of "ASNs" (Address Space Numbers).

In addition such domains hold the root of an additional structure that defines to the kernel the real tables required to support the DAS hardware features. This structure defines the DAS tables in much the same way that memory trees define segment and page tables.

The two ASNs (found in control registers 3&4) are also part of the new domain state.

Except for the fact that entry-table entries have a bit that puts the entered code in privileged mode, the DAS structure could be a tree with pages as leaves and those page serve, unmodified, as a real entry-table to drive the DAS hardware

I think that multiple domains can share a system segment and DAS structure with the semantics of MVS.

IBM's XA {Extended Architecture}
31-bit virtual addressing
This feature requires 1M segments. Gnosis currently uses 64K segments but this is visible only via performance considerations. It seems easy to provide domains that produce 31-bit addresses.

New channel architecture
This seems like a win. It removes some complex code from the kernel and perhaps achieves some performance. The only drawback is that we lose our current optimization whereby we queue two reads for twinned data. The first to get to the head of its queue deletes the other. This seems like a small price to pay.

SIE {Start Interpretive Execution}
The SIE feature is not standard but is necessary or at least highly recommended for VM.

SIE is privileged - there are the following reasons for this that I can discover:

The effective address of the SIE instruction is real and thus the program with the SIE instruction must be trusted.
The SIE instruction addresses a block that holds the state of the guest machine.

The address of the SCA is real too.

The virtual and real change and reference bits interact in strange ways. The operating system must cope with special processing of the storage keys of page frames used by the guest system.

The storage keys are available to the program running under SIE. The rules are unclear.

SIE provides most of the privileged 370/XA CPU architecture relativized to a virtual address space.

The only significant part of the 370 XA architecture that it doesn't support is I/O. The SIE architecture assumes that the program that issues the SIE will be responsible for coping with I/O. The Gnosis virtual machine server could provide I/O by either mapping it into segments or using the current style device driver within the kernel.

Attempted violations to page protection in the virtual space of the program executing the SIE instructions are reported to that program. The program is thus in a position to sense the absence of one of its pages.

See (vm).

Possible Kernel Projects
Move to XA: No Visible New Architecture
This would allow us to run on XA machines that lacked 370 mode. It would harness more than 16 MB real. It would gain the improved channel architecture. Domains would gain no new features.

Implications:

New page and segment tables. Perhaps some kludge to overcome the odious one page minimum segment table size. Perhaps it would be as easy as not to switch from storage key based protection to the page table protection.

Path control instead of Channel control.

Support Multi-processors.

Support DAS via secondary address segment.

Show LASP function to domains.

Provides access to 2**47 byte segments.

Support SIE.

Show PC to domains.

Possible Domain Projects
Support 31-bit PL/I.

Do virtual machine.

See (kernel-logic,xa) for implementation ideas.