Safe Compilation for Hidden Deterministic Hardware Aliasing and Encrypted Computing

TL;DR

This paper presents a compilation technique that ensures reliable code execution despite hidden deterministic hardware aliasing and extends this approach to encrypted computing environments.

Contribution

It introduces a method for compiling code to handle hidden deterministic aliasing and adapts it for encrypted computing, addressing a complex hardware challenge.

Findings

Compilation guarantees consistent memory access in aliasing scenarios

Technique applicable to encrypted computing environments

Addresses a hardware aliasing problem for system reliability

Abstract

Hardware aliasing occurs when the same logical address sporadically accesses different physical memory locations and is a problem encountered by systems programmers (the opposite, software aliasing, when different addresses access the same location, is more familiar to application programmers). This paper shows how to compile so code works in the presence of {\em hidden deterministic} hardware aliasing. That means that a copy of an address always accesses the same location, and recalculating it exactly the same way also always gives the same access, but otherwise access appears arbitrary and unpredictable. The technique is extended to cover the emerging technology of encrypted computing too.

Equations

$$sp+n-\Delta +\Delta$$

$$(mc,{\delta }_R)$$

$$s_0$$

$${sp}^{\prime }+k+\mathbf{\Delta }n\text{where}k=n-{\delta }_R\mathbf{sp}-\mathbf{\Delta }n$$

$$D^s:mc$$

$$D^e:{mc}_e$$

$$D^s:{mc}_s$$

$$D^e:{mc}_e$$

$$D^{s_1}:{mc}_{s_1}$$

$$D^{s_2}:{mc}_{s_2}$$

Full text

1 Introduction

Hardware aliasing describes “the situation where, due to either a hardware design choice or a hardware failure, one or more of the available address bits is not used in the memory selection process.” [1] Its effect used to be familiar to programmers and users alike, as the ‘DLL hell’ that the old 16-bit versions of Windows were prone to. Dynamic linked libraries (DLLs) were problematic for many reasons, but one was that different versions of the same library loaded at the same memory address and all applications referenced the same in-memory copy. So if one application loaded one version of the library then another loaded another version, the first application would unpredictably, as far as the program and user were concerned, find itself in the second library’s code. A virtual extra address bit was the second application loading its version of the library.

DOS users were more familiar with the situation, as expanded memory managers (for memory beyond 1MB) such as QuarterDeck’s QEMM [2] remapped memory so the video graphics and bootstrap (BIOS) code both shared addresses with random access memory (RAM). What a program accessed at runtime at a given address depended on the memory manager, and that decided heuristically. In consequence, program code needed to use standard memory access sequences in order to trigger expanded memory reliably.

The recognisable symptom of hardware aliasing is that what looks to programs like the same memory address (the logical address), sporadically accesses different memory locations (the physical address). With memory-mapped input-output (IO), that may mean different peripheral devices.

Modern applications programmers are more familiar with the opposite software aliasing, in which the same physical resource – memory location or peripheral device – is accessible via different logical addresses. But hardware aliasing has not gone away so much as become irrelevant as hardware has evolved to present a more unified view to software. The paradigm is oblivious RAM (ORAM) [3, 4, 5], a secure RAM solution since the 90s in which memory contents are internally moved about and locations rewritten sporadically and independently to frustrate cold boot attacks [6] (freezing the memory sticks to make the temporary arrangement of electrical charge in RAM last long enough to be analysed when powered off). That internal re-aliasing is not externally visible.

Hardware aliasing arises nowadays notably in the context of encrypted computing [7, 8, 9, 10, 11, 12, 13]. That emerging technology is based on a processor in which inputs, outputs, and all intermediate values exist only in encrypted form. With an appropriate machine code instruction set and compiler, cryptographic semantic security [14] obtains for runtime user data in that environment, relative to the security of the encryption [15] (that means no deterministic or stochastic attack has any more likelihood than chance of successfully guessing any bit of user data, accepting the supposition that the encryption embedded in the machine is independently secure). The lemma there is “encrypted computing does not compromise encryption.” The technology has potential for widespread adoption as near conventional speeds are being attained in recent prototype designs [16, 17]. Because encryption is one-to-many, many bitwise different encryptions of the same memory address are presented to the memory device by the processor (memory is not privy to the encryption). From the point of view of the program, hardware aliasing occurs. The programmer says to write $x$ at address $123$ and the encrypted value 0x123456789a of $123$ is passed to the memory management unit (MMU) at runtime. If the programmer later says to read via address $123$, a different value 0xa987654321 that is an alternative encryption of $123$ may be passed as an address to the MMU, and some content $y$ different from $x$ returned.

An applications programmer must be able to remain ignorant of the hazard. It turns out that there is a compiler mechanism that admits that, and this paper sets it out. The present authors have made suggestions in the past as to what to do [18], but experience has shown those to be too delicate in practice (array accesses via pointer vs. index become incompatible). The technology developed in this paper is more computationally inefficient but requires no semantic changes to source code, and has been deployed and tested (c.f. the HAVOC compiler suite for ansi C [19] and encrypted computing at http://sf.net/p/obfusc).

The solution arrived at depends on the underlying determinisn in processors. Processors are designed to produce repeatable results. Thus the one-to-many-ness of the encryption in the encrypted programming context is a function of hidden extra ‘padding’ and/or ‘check’ bits that accompany the data beneath the encryption. Those bits are calculated deterministically by the processor, and depend on the data and the sequence of operations it goes through. The outcome is so-called hidden deterministic hardware aliasing. The features of that are:

A machine code copy instruction copies the physical bit sequence exactly, such that a copied address accesses the same memory location as the original; 2. 2.

repeating the same sequence of operations produces an address that has exactly the same bit sequence and accesses the same location; 3. 3.

logically different addresses always have different physical bit sequences.

Condition 1 (‘faithful copy’) means the compiler can save an address for later use after writing through it, and it will work to retrieve the written value. The address must not be altered, not even by adding zero, as calculation alters the hidden padding or check bits and hence the physical representation as a sequence of bits, which then fails to access the same memory location as before.

Condition 2 (‘repeatability’) allows for some calculations on addresses, so long as they are repeated exactly each time. That is useful because the machine code instruction to read or write a memory location takes a base address $a$ in a register and adds a displacement $d$ embedded in the instruction to get address $a+d$ for the access. It is impossible to avoid the processor doing at least that one addition. But that does not matter because the same calculation is repeated each time the address is needed, with the same sequence of bits resulting.

Condition 3 (‘no confusion’) guarantees that the representations as physical sequences of bits of what look like different addresses to the processor and program do not step on each other. Equality as measured programmatically partitions the space of physical bit sequences representing addresses into disjoint equivalence classes. Each is the set of possible representations as different bit sequences for a single logical address. That abstraction does capture the situation where extra check bits or padding are ignored by the processor’s arithmetic.

The layout of this paper is as follows. Section 2 explains how to compile to obtain code ‘safe against hardware-aliasing’ in the most general context. Section 3 details the extension for compilation in the encrypted computing context. The compiler must vary the generated object code maximally while maintaining the same structure (and the same runtime trace structure). The technique introduced in Section 2 copes with apparently unreliable addressing that is fundamentally deterministically generated and the technique of Section 3 extends that to both generate and cope with apparently unreliable data.

2 Compilation for Hardware Aliasing

The compiler principle followed in this paper is that each address that is written is intended to be saved for later read, as per Condition 1 of Section 1. The conundrum in that is that it is saved at an address, which must also be saved, and so on recursively. Condition 2 puts a backstop on the potentially infinite recursion, allowing addresses that are calculated at compile time by the compiler to be used instead. But a finite set of addresses cannot suffice for nested function calls to unbounded depth, so the runtime stack must be involved. The real first problem to be solved is how to manipulate the stack pointer so addresses and other data might be saved and recovered reliably from stack.

2.1 Stack Pointer 101

Standard compiler-generated code decrements the stack pointer register sp by the amount that will be needed for local storage in the function immediately on entry to the function body, and increments it again just before exit:

call to* function* …

• function* code start: decrement** sp** … increment** sp** return

That does not work in a hardware aliasing environment, because the increment does not restore exactly the physical representation originally in the stack pointer register. Instead, the caller gets back a different set of bits that means the same thing to the processor. Being different, it references a different area via the MMU.

The frame pointer register fp must be co-opted to save the stack pointer in, and the stack pointer restored from it on exit:

• function code start: copy** sp** to** fp** decrement** sp** … copy** fp** to** sp** return

That is the typical form of unoptimised function code from a compiler. Compiler optimisation ordinarily replaces it with the previous (stack pointer -only) code. The GNU gcc compiler (for example) with -fno-omit-frame-pointer on the command line turns off optimisation and produces the code immediately above.

That is not quite perfect because the caller’s frame pointer register must also be saved and later restored, as follows:

• function code start: save old** fp** to 1 below** sp** copy** sp** to** fp** decrement** sp** … copy** fp** to** sp** restore old** fp** from 1 below** sp** return

Saving below the caller’s stack pointer puts it in the callee’s stack area (‘frame’), so its stack requirement (‘frame size’) is over-stated by one in the decrement to make room for it. As many as the compiler wants of the caller’s registers can be saved at the top of the callee’s frame. The application binary interface (ABI) document for the platform specifies which registers the callee must save, and which the caller code must expect may be trampled and must save for itself.

Rather than decrement the stack pointer again for blocks of code with their own local declarations within a function declaration, the compiler holds the stack pointer constant and reserves space for subframes within the function frame. That makes the function frame uncomplicated to access from within sub-blocks.

The final code above works with hardware-aliasing. It sets up storage for the function on the stack (the ‘local frame’) that can be reliably addressed as ${\it sp}+d$ from within the function code in a hardware-aliasing environment, where $d$ is a displacement between 0 and the frame size, provided as a constant in a load or store machine code instruction, and sp is the stack pointer register value.

2.2 Accessing Variables

Given the setup described above for the stack pointer, accessing function local variables is simple. A word-sized local variable x is assigned a position $n$ on the stack and the compiler issues a load instruction to read from there to register $r$:

lw* r n*(sp) # load from offset $n$ from* sp*

The processor does addition ${\it sp}+d$ in executing the instruction, but repeats that calculation at every access, so by Condition 2 of Section 1 the same sequence of bits for the address is produced every time, and it accesses the same spot in memory via the MMU. To write the variable, a store instruction is used instead:

sw* n*(sp)* r* # store to offset $n$ from* sp*

For global variables, which reside at a compiler pre-decided address $a$ in (heap) memory, the compiler offsets from the zero register zer instead of sp:

lw* r a*(zer)  # load from address $a$

The zero register contains a fixed zero value (that speeds up computations as zero is frequently needed). The address presented to the MMU by this instruction is $a+0$, which is a different sequence of bits to $a$ (representing the same value to the processor), but it is what is always presented so the same memory location is always accessed. The compiler also pre-calculates the bit sequence for $a+0$ and puts data into the executable/loadable file (ELF) for the program loader to load at the location before program start, to provide an initial value.

Variables in the parent’s frame may also be accessed. If the function is defined within another function, it is an interior function, and the parent’s local variables should be notionally in scope for it. The parent’s frame pointer is handed down at runtime in the c9 register (that register is specific to the platform ABI). The register is saved through successive daughter function calls along with the frame pointer register. Then a load or store instruction using c9 instead of sp or zer reliably accesses the parent function’s local variables.

2.3 Accessing Arrays

The elements of array $\bf a$ can in principle be accessed either via a load or store instruction with fixed displacement $n$ from the array address $a$ (that is ‘$a[n]$’), or via a pointer with value $p$ that ranges through the array starting at $a$ and steps through the elements until the desired one is reached, at which point a load or store instruction with displacement 0 from the pointer (‘$p[0]$’) is applied [18]. The two calculations for the address that is finally sent to the MMU are respectively $a+n$ and $a+1+1\dots+1+0$. The calculations produce different sequences of bits to be presented to the MMU for notionally the same address, so the two methods are incompatible and one or the other must be preferred. But in practice both have proved too restrictive. It is as common, for example, for real code to step a pointer down through an array as to step up through it, and the transformation the compiler needs to do is prohibitively expensive.

We have accepted as engineering compromise that array access is not for general purposes going to be constant time in this environment. For arrays of size $N$ the compiler can provide access in $\log N$ time in a simple manner that is safe against all programmed methods of calculating an index or pointer. On our own encrypted computing platform, it is even preferable that array access be linear time, because in order to obscure which array element is accessed, the code must step through them all, summing each entry in turn into an accumulator multiplied by either 1 or 0 (encrypted) according as the entry is the one targeted or not. Since the multipliers are encrypted, an observer not privy to the encryption cannot tell which multiplier is a 1 and which is a 0.

Linear complexity code will be presented first. To read (local) array element $\bf a[n]$ the code tests $\bf n$ against each of $0,\dots,N{-}1$ in turn and uses a compiler-generated address for the lookup:

(n == 0)?a[0]: (n == 1)?a[1]: …

The equality tests are insensitive to the representation of the same value $n$ of n as possibly different sequences of bits since they take place in-processor, which discards any hidden padding and check bits. This code always passes address $a+d$ to the MMU, where $d$ is the displacement from the base of the array and $a$ is address ${\it sp}+k$, where $k$ is the position on the stack allocated by the compiler for the lowest array element $\bf a[0]$.

lw* r d*(r)  # load from address $a+d$ with $a$ in* r* to* r*

The address $a$ is supplied to the base address register $r$ by a prior instruction:

addi* r** sp*** $k$ # add $k$ to* sp* in* r* lw* r d*(r)   # load from address $a+d$ with $a$ in* r* to* r*

and this always produces the same calculation ${\it sp}+k$ for $a$.

Improving this code to $\log N$ complexity means using a binary tree structure instead of linear lookup for the value $n$ of n, deciding first if $n$ is below $N/2$ or above it, then on what side of $N/4$ or $3N/4$ it is, and so on. Code for writing to $\bf a[n]$ follows the same pattern, with store instead of load instructions at the leaves of the binary tree or linear code sequence.

The same code structure works for access via a pointer p, provided the compiler is sure which array it points into. We have tightened the type system of the source language (C, in our case) so the pointer is declared along with the name of a (possibly overlarge) array a into which it will definitely point at runtime:

int *p restrict a

The restrict keyword selects the target array for the pointer. This embellishment means a certain amount of porting has to be done for existing code, marking out global areas into which pointers can point. It generally means declaring a global array from which objects of the kind pointed to are allocated from, or declaring a function as interior to another function where the target of the pointer is defined as a local. As the new pointer type is narrower than the original and (ideally) we make no semantic changes, confidence in type safety should be increased.

Then the following code does lookup via pointer p:

(p == a+0)?a[0]: (p == a+1)?a[1]: …

It is as insensitive to the way the pointer $\bf p$ is calculated in a dereference $\bf*p$ as is the lookup code for $\bf a[n]$ insensitive to the way $\bf n$ is calculated. The code can similarly be made over to $\log N$ complexity with a binary tree lookup structure, and converted to write by replacing load instructions at the leaves with stores. These constructions make pointer access the same as access via array index.

If a size N of the array is declared dynamically in the local function, then more dynamic code must be generated. What matters is that the compiler always causes the same calculation to be used for the address finally sent to the MMU. The following generated code writes reliably through pointer p:

for (int d=0; d<N; d++) if (p == a+d) { a[d]=x; break; }

The address passed to the MMU is $sp+k+(0+1+\dots+1)+0$, where $a={\it sp}+k$ is the address of array a, and the 1s are repeated $d$ times to address a $d$th element of the array. The same form must be used for indexed write:

for (int d=0; d<N; d++) if (n == d) { a[d]=x; break; }

The calculation for the final address passed to the MMU is the same and always accesses the same memory location as per Condition 2 of Section 1.

2.4 Multi-word Types

Records with named fields (‘struct’ in C) are treated by the compiler as arrays and the field name is translated to an array displacement. The declaration

struct { int a; int b; } x

declares x with two named fields, a and b, each one word wide. It occupies two words on the stack at displacements $k$ and $k^{\prime}$ (the value $k+1$) respectively from the stack pointer. The compiler generates accesses to x.a and x.b just as it would for any local variables situated there, by calling

lw* r k*(sp) # load from ** x.a**

to read from x.a, for example. The address passed to the MMU is ${\it sp}+k$. To access x.b, the address passed is ${\it sp}+k^{\prime}$ instead. With the code the compiler generates for array access, source code attempting unsafely to access the fields of the struct as though it were an array also works, which helps in porting.

Long atomic types such as double are also treated this way (i.e., as arrays) when distinct machine code instructions are required to access each component words on the stack. But most platforms have double-word load and store instructions that will fetch/write two words at once:

ld* r k*(sp) # double word load

and only the address of the first word is given in this case. Registers are indexed as pairs for this instruction, and the pair to $r$ is loaded up by the instruction too. But then source code that does try to access the second word as though the double were an array of length 2 will not work. The address used by the MMU will be one more than the bit sequence for ${\it sp}+k$ but the address passed to the MMU by the array-oriented code generated by the compiler will be the bit sequence for ${\it sp}+k^{\prime}$, where $k^{\prime}$ is $k+1$. Those are different. Overall, it is safer that the compiler not generate double word instructions.

2.5 Short Types

The difficulty remarked above in accessing the second word of a double in memory translates to a difficulty in accessing the individual bytes of a word. The platform usually provides instructions that access memory a byte at a time, but the address that the MMU knows for the second byte of a word will be one more than $a$, the sequence of bits that the processor produces to represent the address of the word. If the processor produces instead a sequence of bits representing $a+1$, that in all likelihood will not be the same. Padding and check bits may differ. To the processor it is all the same, but the MMU is not privy to the secret of what bits to take notice of and what to discard, and to it the addresses look different, and access different bytes in memory.

For index-oriented access to the characters of a string a, the compiler generates code that splits the character index i into index $\bf d$ for a word consisting of a sequence of 4 characters, and offset $\bf j$ for the wanted character within the word:

d = i/4; j = i%4;

Then the character is obtained via an array-of-words lookup and arithmetic:

(a[d] / 256j) % 256 # $j$th char of $d$th word

If the string starts in the $k$th stack position and $k^{\prime}=k+d$, the a[d] part will result in the form of load instruction already noted in Section 2.4:

lw $r$ $k^{\prime}$(sp) # read at offset $k^{\prime}$ from* sp*

In our own compiler for our own (encrypted computing) platform, we have preferred to avoid the complication and pack characters only one to a word, at the cost of an inefficient use of memory. Then no special treatment is required. That is also helpful in the encrypted computing environment because characters have reduced entropy (the choice is from 256 alternatives) and it is better from the point of view of defense against stochastically-based attacks to bury them in whole words beneath the encryption, where the rest of the word is random.

3 Encrypted Computing

Although hardware aliasing takes place ubiquitously from the point of a program running in an encrypted computing environment, that is not the only hurdle that a compiler for that context has to overcome. In particular, for the security of the encryption, the compiler has to vary the underlying code and data in order to swamp out human programming influences that could lead to statistically based attacks. If zero is the most common data item flowing through a processor running human-generated code, it could pay to mount a ‘plaintext’ attack [20] on the encryption supposing that a given encrypted datum is zero.

3.1 Address Displacement Constants

Instead of generating a load instruction to read from a variable at position $n$ on the stack like this (Section 2.2):

lw* r n*(sp) # load from offset $n$ from* sp*

the compiler will issue the instruction with a different displacement constant $\Delta$:

lw* r* $\Delta$(s) # load from offset $n$ from* sp*

Here $\Delta$ is a previously chosen random number and the register $s$ has been pre-set with the value ${\it sp}+n-\Delta$ to accommodate this, where sp is the nominal value for the stack pointer. The bit sequence passed to the MMU is from

[TABLE]

which is always the same when that calculation is repeated (Condition 2, Section 1).

The compiler always emits the same instruction pattern, but it has to ensure separately that the $\Delta$ used is always the same for the same $n$. It maintains a vector ${\bf\Delta}$ indexed by stack location $n$, as well as a similar vector ${\bf\Delta}_{Z}$ for the heap. Then the $\Delta$ in the load instruction above is ${\bf\Delta}n$:

lw* r* ${\bf\Delta}{n}$(s) # load from offset $n$ from* sp*

The change from $n$ to ${\bf\Delta}n$ for the displacement constant is a mark of the passage from the hardware aliasing context to the aliasing and encrypted computing context. In the latter context the generated code must vary over recompilations as further explained below. The change from $n$ to a randomly chosen ${\bf\Delta}n$ as an embedded constant in the instruction is part of that.

3.2 Content Deltas

As remarked above, the stack pointer sp does not contain the value sp that it notionally should have but instead is offset from that by a random value $\delta$. That is true of the content of every register at every point in the generated code. The compiler maintains a vector ${\bf\delta}_{R}$ of the offset delta for content in each register $r$, varying it as it passes through the code. Let a non-side-effecting expression $e$ of the source language be translated by the compiler $C_{r}[-]$ to machine code mc that targets the result for register $r$. Let the state of the runtime machine before mc runs be $s_{0}$, let the nominal value for the expression be $[e]^{s_{0}}$, then

[TABLE]

The ‘nominal value’ $[e]^{s_{0}}$ of $e$ is is formalisable via a canonical construction: map a variable $x$ in the expression to its register location $r_{x}$ (the runtime value is offset by a delta ${\bf\delta}_{R}{r_{x}}$), checking the content of $r_{x}$ in the state and discounting the delta to get $[x]^{s_{0}}=s_{0}(r_{x})-{\bf\delta}_{R}\,{r_{x}}$. Arithmetic in the expression is formalised recursively, with $[e_{1}+e_{2}]^{s_{0}}=[e_{1}]^{s_{0}}+[e_{2}]^{s_{0}}$, etc.

The compiler also maintains a vector ${\bf\delta}$ for the delta offsets of stack contents indexed by stack location $n$, and a vector ${\bf\delta}_{Z}$ for the delta offset of heap contents indexed by heap location $n$. A window onto code generated for access to the $n$th location on the stack shows:

addi r** sp** $k$ # where $k=n-{\bf\delta}_{R}\,{\bf{sp}}-{\bf\Delta}{n}$ lw* r* ${\bf\Delta}{n}$(r) # read $n$th location on stack

The address is placed in $r$ for the load and then overwritten with the content loaded from the location. The MMU receives the bit sequence for the calculation

[TABLE]

The stack pointer register sp contains the value ${\it sp}^{\prime}$ which is offset by ${\bf\delta}_{R}\,{\bf sp}$ from the nominal value sp of the stack pointer. Summing, the address has the value ${\it sp}+n$. The calculation is the same every time so the bit sequence passed to the MMU for the address is the same every time, by Condition 2 of Section 1. A write replaces the load by store and passes the same bit sequence to the MMU.

The $\bf\delta$ and $\bf\Delta$ values are changed randomly by the compiler at (just before) every point in the code where a write occurs. The delta for any register $r$ is changed at every write to it. A theorem in work of ours presently under review [21] measures the variability in a runtime trace in terms of its entropy viewed as a stochastic random variable over recompilations of the same code (the entropy is the expectation $E[-\log_{2}p(T)]$ for traces $T$ that occur with probability $p(T)$, and it expresses the number of freely variable bits that parametrise the trace):

Theorem 3.1

The entropy in a trace over recompilations is the sum of the entropies of every instruction that writes that appears in it, counted once each.

An instruction has entropy inasmuch as its effect can be varied by the compiler from recompilation to recompilation by changing the constants embedded in it.

Machine code instructions like load and store that merely copy from one place to another do not contribute entropy to the trace except as they may write to different places. Variations in the displacement constant in the load instruction contribute to that by changing the calculation and hence the bit sequence passed to the MMU for the same address.

The compiler varies the contribution ${\bf\Delta}n$ in the addi instruction in the load sequence above, supplying a potential 32 bits of entropy (or 64 bits, etc., depending on the word size). But ${\bf\Delta}n$ is fixed through reads, and only varied at writes, so it is old news when it runs and there is no entropy contribution (unless read is not preceded by write – perhaps it is pre-loaded read-only program data).

Consideration of detail like that apart, the compiler’s job in the encrypted computing context is to do everything it can to maximise entropy in the trace:

Theorem 3.2

The trace entropy is maximised when the compiler varies every instruction that writes individually to the maximal extent possible (i.e., randomly, with flat distribution) from recompilation to recompilation.

That varies the data in the trace at runtime between different recompilations and provides a stochastic setting in which an attacker cannot be sure what the numerical value of the unencrypted data should be, even in terms of a statistical tendency, because all inputs by the programmer are swamped by the contribution from the compiler. The latter provides an extra, additive, uniformly distributed input at each instruction at which it is able to. That distribution has maximal entropy over the 32 bits (or 64 bits, etc.) available. The combined signal from programmer and compiler cannot have less entropy (‘Shannon’s Law’ [22]), so it too has maximal entropy at that point, which means that the values at that point in the trace beneath the encryption are uniformly and evenly distributed as a probability distribution. That means data beneath the encryption in the trace is no more vulnerable to statistical plaintext attack than random (encrypted) data is, though the program is designed by a human and executed deterministically.

Structural limits on the compiler-induced variation are explained below.

3.3 Loops

Loops (while, for, backward goto, etc.) induce losses in the freedom of choice for compiled code. Let the statement compiler $C[-]$ produce code ${\it mc}$ from statement $s$ of the source language, changing the combined database $D=(\Delta,\Delta_{Z},\delta,\delta_{Z},\delta_{R})$ to $D^{s}$ in the process. For legibility, pairs $(D,x)$ will be written $D:x$ here:

[TABLE]

The notation makes explicit that the compiler is side-effecting on $D$.

Compiling a loop while $e$ $s$ standardly means emitting code mc constructed from the code ${\it mc}_{e}$ for $e$ and the code ${\it mc}_{s}$ for $s$ with the following shape:

start: mce # compute $e$ in $r$ beqz $r$ end # goto to end if $r$ zero mcs # compute $s$ b start # goto start end:

The compiler produces ${\it mc}_{e}$, then ${\it mc}_{s}$, in that order:

[TABLE]

That does not work as-is, because the code does not at the end of the loop reestablish the deltas that existed at loop start, so the second time through, much goes wrong. Extra code is needed after ${\it mc}_{s}$, so-called ‘trailer’ instructions.

A trailer instruction that restores the content of register $r$ to its initial delta ${{\bf{\delta}}_{R}}\,r$ off the nominal value from the final delta ${{\bf{\delta}}_{R}^{s}}r$ off nominal is

addi $r$ $r$ $k$ # add $k={{\bf{\delta}}_{R}}\,r-{{\bf{\delta}}_{R}^{s}}\,r$

Trailer instructions that restore the $n$th stack location offset also restore the displacement constant used in load and store. The temporary register t0 is loaded using the final loop displacement ${\bf\Delta}^{s}n$, the offset of the content is modified, then stored back using the original loop displacement ${\bf\Delta}n$, ready for the next traverse:

addi** t0 sp** $j$ # $j=n-{\bf\delta}_{R}\,{\bf{sp}}-{\bf\Delta}^{s}n$ lw** t0** ${\bf\Delta}^{s}n$(t0) # load $n$th stack location addi** t0 t0** $k$ # modify by $k={{\bf{\delta}}n-{{\bf{\delta}}^{s}}}n$ addi** t1 sp** $l\,$ # $l=n-{\bf\delta}_{R}\,{\bf{sp}}-{\bf\Delta}n$ sw ${\bf\Delta}n$(t1)** t0**   # store $n$th stack location

The first two instructions are exactly the read stack code of Section 3.2, and the last two instructions are the corresponding write stack code. The stack pointer does not change from beginning to end of the loop, nor does the offset $\delta_{R}{\bf{sp}}$ of its content from the nominal value sp, so it appears unaltered through that code.

The instructions above are determined by choices of deltas by the compiler for earlier instructions. It is impossible to execute the trailer instructions without traversing the loop body, which will execute those earlier instructions, so these trailer instructions are always ‘old news’ and introduce no entropy into the trace.

3.4 Conditionals

The synchronisation problem described above occurs wherever two distinct control paths join, and after an if-then-else block in particular. The final deltas in the two branches/paths must be equalised. The compiler emits final ‘trailer’ instructions for that purpose. Code mc for if $e$ $s_{1}$ else $s_{2}$ standardly has shape:

start: mce # compute $e$ in $r$ beqz $r$ else    # goto to else if $r$ zero mc${}_{s_{1}}$ # compute $s_{1}$ b end # goto end else: mc${}_{s_{2}}$ # compute $s_{2}$ end:

where the order the compiler works in is ${\it mc}_{e}$, ${\it mc}_{s_{1}}$, ${\it mc}_{s_{2}}$:

[TABLE]

But that code does not work because it also needs trailer instructions after ${\it mc}_{s_{2}}$ to set the final deltas in the ‘else’ branch equal to the final deltas in the ‘then’ branch. Each has the same pattern as a trailer instruction for loops.

Other notable places where trailer instructions are required are the label targets of gotos, and at return from functions. Calls of interior functions also require ‘trailers’, but before the call, because the context in which the function was defined must be reestablished (effectively a ‘come from’ imperative).

4 Implementation

Our own prototype C compiler http://sf.net/p/obfusc covers ansi C and GNU C extensions, including statements-as-expressions and expressions-as-statements, gotos, arrays, pointers, structs, unions, floating point, double integer and floating point data. It is missing longjmp and efficient strings (char and short are the same as int), and global data shared across code units (a linker issue due to the who-decides-the-delta conundrum for code compiled first but referencing as-yet uncompiled external global data).

A trace111Initial and final content offset deltas are set to zero here, for readability. of the Ackermann function222Ackermann C code: int A(int m,int n) { if (m == 0) return n+1; if (n == 0) return A(m-1, 1); return A(m-1, A(m, n-1)); }. [23] compiled by that compiler is shown in Table 1. The trace illustrates how the compiler’s variation of the delta offsets for register content through the code results in randomly generated constants embedded in the instructions and randomly offset runtime data.

Running a Sieve of Eratosthenes program333Sieve C code: int S(int n ) { int a[N]={[0…N-1]=1,}; if (n$>$N$||$n$<$3) return 0; for (int i=2; i$<$n; ++i) { if (!a[i]) continue; for (int j= 2*i; j$<$n; ++j) a[j]=0; }; for (int i=n-1; i$>$2; –i) if (a[i]) return i; return 0; } .

for primes shows how memory access is affected by address displacement constants. The final part of the trace is shown in Table 2 with two stack reads in red and the address base and address displacement in blue. The assignments to these stack locations are up-trace and do have the same address base and displacements as in the later reads:

19300 addi t1 sp -407791003 t1 $\leftarrow$ -866593752|1532548040 19320 sw 866593746(t1) t0 mem[-6|-712377144] $\leftarrow$ -866593745|1800719299 … 20884 addi t1 sp -1763599776 t1 $\leftarrow$ 2072564771|-1935092797 20904 sw -2072564772(t1) t0 mem[-1|1518992593] $\leftarrow$ 2072564779|-1773201679

The memory addresses -6, -1 reflect that the stack grows down from top of memory (-1), but it is the combinations -6$|$-712377144 and -1$|$1518992593 of address and hidden bits together that are looked up by the MMU.

5 Conclusion

This paper has described the compilation of imperative low level source code for a platform that has hardware aliasing with hidden determinism. The technique depends on the compiler controlling exactly the address displacement and address base for load and store instructions so that they are always the same for repeat accesses to what is intended to be the same memory location. That means they are either copies or the calculations for them exactly reprise the earlier calculations. It is surprising that the trick can be worked in such a systematic way, but it can further be extended to both generate and cover for displacements in the data content of registers and memory in the context of encrypted computing. There it is essential for the security of encrypted data passing through the machine that it may have been varied by a maximal entropy input from the compiler, which swamps statistical biases that arise from human programming.

The mechanism described in this paper is log or linear complexity for array access. Constant complexity would be possible but at the price of making index- and pointer-based accesses mutually incompatible, which would necessitate invasive changes in ported source code.

In the encrypted computing context, the existence of this kind of compiler validates those processor designs that pass encrypted addresses as well as data to the memory unit, which remains fully ignorant of the encryption.