Durability of Forts

The factory builds an object in an environment out of which it is impossible to export data despite coordinated efforts of code in the environment and outside it. A fort is a sort of dual factory that provides an object in an environment into which it is impossible to import data, despite coordinated efforts of code inside and outside the environment. As the factory is the source of discreet objects, the fort is the source of environments into which no signals can flow, except as provided by the requestor of the environment. See “isolate” in this terminology. Normally the fort will also take steps to make its own future availability manifest.

The Gnosis manual introduces these and yet more general ideas here. The factory has been implemented and heavily used. The fort has not been implemented.

This supports durable services such as compilers. Such a service can provide assurance that it will respond to a query next year just as it would respond to the same query today. Such assurance does not depend of the compiler’s code. This cannot ensure that you will not find a bug next year that you are unaware of now, but does ensure that you will encounter no bugs next year that are not there now. You can be sure that new compiler releases or date dependent features will not break your ability to compile your code. It also guards against reallocation of critical storage by someone who does not know the use of some function.

Some program owners may be unwilling to provide perpetual access but might install a visible vulnerability at one year. The customer is thus aware of when the program that he buys will expire and need not trust the provider’s promise that it will not expire sooner.

first, Durable Segments

The kernel assures the factory that sensory keys can produce no side effects. The fort requires analogous assurance concerning segments to be accessed by the fort’s yield. The required property is that the segment will remain with its data unaltered, all subject to only identified vulnerabilities. If the space bank implements a sever-but-don’t-zero for pages and nodes this will be more efficient. With access to the bank from which the old segment is built, the ownership of pages of the segment can be transferred to a new durable bank without I/O. The program that does this is in the durability TCB.

Here are some alternatives for building durable segments:

A trusted durable segment creator that copies data from another segment all at once into a newly created segment created from material from some durable space bank.
A trusted segment keeper DSC that builds a writable segment but then turns it to stone upon command after which it is read-only and durable. The DSC would have to stay around to vouch for the segments that it had created.
An extension of VCSK which produces a mutable segment of known initial state. If VCSK were willing to expose its structure (now abstracted) and that was a sensory tree of nodes and pages (which it is), then an efficient simple program could produce an exact copy of the tree, produced from a durable bank. An inherent limitation is that unless all on the ancestors of a VCSK are durable, there may be non durable stuff in the segment. Copying is necessary in general. VCSK is capable of doing this or invoking a copier that it trusts to see its structure and that is trusted by others to produce durable segments.

Any of these will work but more thought can produce better designs.

Possible Fort Design

Since the fort is conceived of as a permanent source of things (with identical initial state), I will assume that each fort consists, in part, of a factory — the fort’s factory. To a considerable extent the fort delegates much work to its factory but checks additional rules. The fort acts as a front-end to the factory builder’s key. It will probably export the factory requstor’s key to anyone who asks. You know that such a factory produces known state objects because of where you got the factory. Forts vouch for each other as do factories. Forts also reveal relative vulnerabilities as factories reveal holes.

The Durable Installation of a Data Base System

We describe the steps taken by someone who wants to make his DBS available on a machine and also convince yet unknown users, that it will not go away except under circumstances to be described. We assume that the installation occurs over a remote network as that illustrates several interesting security problems. If this installation is happening on the machine of a purchaser of the DBS then these steps will be taken by installer which is installation code written by the DBS owner.

The installer is launched with access to a collection of pre-existing standard services. In this directory are a few fort keys. The installer invokes a fort creator and gets a new nascent fort F, which at the end of the installation will become the fort providing permanent access to the DBS functionality and will be available to subsequent application installers. For simplicity we assume that the DBS code has need of a B-Tree service which is itself provided by an older fort.

Here are the capabilities that the DBS installer will need from local sources:

A space bank from which to acquire permanent storage,
A permanent meter that will run just a bit when the fort in invoked for a new instance.
A meter and space bank for use during installation,
A capability to the fort that produces B-Tree objects,
A capability to the fort creator,
A capability to the factory creator (?),
A communications capability over which to fetch DBS code,

Here is a hypothetical sequence of events carried out by the DBS installer: (Remember that the installer is trusted only by the DBS owner and even he may not trust the installer to be uncorrupted!)

Invoke DSC builder to get a new DSC passing the permanent space bank. This yields an initially writable segment.
Fetch code over the communications link and store it into the new segment.
Instruct the DSC to petrify the segment.
Invoke the fort creator for a new fort passing the permanent bank and meter.
Install the new segment as a component in the fort with a claim of invulnerability which the fort will verify. The fort extracts the bare memory tree, which is sensory and passes it into the fort’s factory which verifies that it is sensory.
Install the B-Tree fort as a component in the fort. The fort will verify that it is a fort requestor’s key. The fort will augment its own vulnerabilities with those for the B-tree fort.
Instruct the fort to become immutable. This returns a fort requestor’s key.
Return the fort requestor’s key to the invoker of the installer.

We may provide forts with known vulnerabilities, which yield access to a factory.

more Fort Design

A fort is composed of a factory builder’s key, and a set of vulnerabilities. Here are some orders on the builder’s key of the nascent fort:

To be continued...

Access by Hash

It would be good to establish a broadly available service that kept durable segment designed to be shared and identified by secure hash. One could contract with the service for established durability. There is a “skin in the game” issue of incenting termination of requirement for access to such shared segments. Money will solve this.

Some Ramifications

I choose a data base management system to illustrate a limitation of forts. The fort can assure that new data bases can be instantiated but cannot assure that a given instance will continue to serve indefinitely. The data base instance could have a counter that quit after 1,000,000 transactions. This drawback does not apply to the compiler example.

Here are some common reasons why software stops working that forts fix:

The application clobbers itself on the disk.
Some competing product seeks out and clobbers the application.
Some other application, trying to be helpful, configures the word so that the new application owns some resource, thereby stealing it from the original application.
The application writer puts in a time bomb.
The application has a Y2K problem. (Note that most applications need not know the date, and if they think that they do, a false date will probably suffice!)
The application depends on a bug in some shared library.

Here are some “availability” problems that the fort doesn’t fix:

The long lived instance described above.
Signals entering embedded in legitimate application input, that are designed to signal the application to stop, as in extortion by the application author. This is difficult to arrange for most applications.
Failure of underlying data that is not repaired by kernel raid-like function.
Uncaught CPU errors that corrupt the entire system!
Accidental deletion via the legitimate authorized user actions.

We have not talked about the interests of the application owner. The hardware platform may be tamper-proof to some degree and then some corresponding assurance could be given to the application owner that some TCB would remain in control. The kernel and the fort would be part of the TCB that would concern the application owner. There remain loose ends here.

More Ramifications

This design makes sense only in the context of some sort of higher level object that wields a fort and acts as an arbiter among critical users of objects produced by a fort. I write here as if those users were people with e-mail addresses, which might actually be the case. They are the people who are responsible for continuity of some critical service and a budget to match that responsibility.

There is obviously a partially political problem of how the cost of supporting some particular yield of the fort. There are many non-rivalrous resources within large companies. This is the same problem long studied by accountants who must assign costs of supporting some shared resource among the users within a corporation of that resource. That also includes the coordination necessary to decide when to cancel such support. Enough said I think, having reduced it to a previously unsolved problem.

In a system that is open to entrepreneurs, one such may put money in escrow to preserve some object until the escrow agent is satisfied that conditions are met for destruction of the object, and negotiate contracts with some set of potential users. The contract can include payments to the entrepreneur under conditions which can be audited by the contract holders.

See Charlie Landau’s characterization of the problem, and a solution. See note on reproducibility. Forts overlap and complement functions of the apartment. Are kernel hooks needed?