The fort requires some sort of reproducibility of program execution. What are useful concepts regarding reproducible execution a body of code that do not depend on the logic of that code. Here are some:
  1. Running untrusted code twice so that, with the same input, the same output will result.
  2. Running untrusted code so that it has the same probability of outcomes on each execution.
  3. Running untrusted code that has exactly the same gamut of possible outcomes on different runs. Said otherwise each execution will produce one of the outputs that previous executions might have produced.
Systems that provides such features must lack certain other features! The IBM 370 had five carefully documented user-mode instructions whose effects were not entirely determined by the previous user mode state. One instruction would copy a byte string, reversing the order. The result was indeterminate if the operands overlapped. In fact this probably depended only on the 370 model and operand addresses. If so this would not lead to non-reproducibility, unless one needed to move between models between executions.

In such cases the hardware manual was careful to specify that the noise introduced by these instructions was not secrets of some other program state. They called this “bounded indeterminism”.

Other 370 instructions (MVCL, CLCL) were interruptible by virtue of leaving instruction headway information in the same registers that parameterized the instruction upon initiation. The fact of an interrupt was visible to the program that examined the registers after the MVCL finished.

If the program has the authority to launch multi processor threads, then one cannot ensure reproducibility. This indeterminacy could be eliminated by a compatible hardware architectural change that rewrote the four register values upon completion of an MVCL. Perhaps it is possible to degrade performance by not actually providing multiprocessing, or transparently providing only multi-programming in its stead.

Keykos suggested but did not implement a meter mode under which only one domain could be active. A fork to another domain under the same meter would invoke the meter keeper.

One scheme would provide three processing modes:

Not all interrupts need be recorded. Time slices among multi programmed threads, must be replayed somehow. Few if any current processors have equipment to do this. Processors have, in the past, had “instruction counters” that counted, not located, instructions. These could be used to re-execute a program and time slice on replay the same as on play.

I once heard that Siemens had produced a machine capable of reproducible execution in order to support a strategy where transactions would replay and be assured of producing the same result if failure lost all but the inputs of the transaction.