Avoiding Hardware Aliasing

Peter T. Breuer and Jonathan P. Bowen

Birmingham City University

Peter.T.Breuer@gmail.com

Imagine the Lander is on Mars

● A cosmic ray tracks through the processor Arithmetic Logic Unit

– From then on 1+1=3

● How do we save the mission?– An answer turns out to be 'reliable' code

● Resistant to errors of this kind

Extreme: every operation 'wrong'

● Krypto-Processor (KPU)– Natively encrypted computing

● Instead of 4 - 4 = 0 ...● 99900 - 99900 = 78763298

– Potential Holy Grail Security Cure-All

● Encryption is 1-to-many

99900(4) + 78763298(0) = 2980(4)

Same address (4) accesses

different memory (99900, 2980)

?

Called Hardware Aliasing

● Two devices/memory live at one address– E.g. old Windows shared library problem

● All versions load at same address● Applications get unexpected functionality

– Still around today ● M/S mem-maps library files by basename

➔ different versions of same library in same directory don't work. Also .net (sub-4)

– Application sees same address access different resources haphazardly

Different cause, different rescue

● Don't use processor register with stuck bit● Pre/post-correct ALU arithmetic● Don't use stuck bit half of address space● Applications use static libraries, not DLLs

The messed-up arithmetic case

● Model: Imagine there's a devilmessing with calculations:

● Think: values have invisible extra bits● 42.1101101● Represents the many ways of saying '42'

● Processor ignores and mutates extra bits● 42.1101101 + 42.1100001 = 84.0110110

● Memory/peripherals sensitive to extra bits● Don't see '42', see '42.1101101'.

Fixing Processor Arithmetic

Clue: processors are

Deterministic behind the scenes

No matter how haphazard it seems

Solution: deterministic

programmer loving care

Krypto-processor (KPU) case

Many different bit-patterns signify same address

'messed-up on purpose'

Data in one of the crypto-equivalent addresses!

1011

(&4)

&99900 &2980

Soln: always calculate same address same way

Deterministic ⇒ same bit-pattern as address

Example

● Left program returns different alias to caller SP – 32 + 32, SP equivalent, not identical

Subroutine foo:

SP -= 32 # 8 local vars…code ...SP += 32 # destroy framereturn

Subroutine foo:GP = SPSP -= 32…code ...SP = GPreturn

GoodBad

Use typing

● Milner typing– Assign type variables to every register

and local stack position

– Distinguish by type● Data● Data address

– Array data address– String data address

● A type-correct machine code …– Will calculate each address the same way

Call stack

● Variables in the local frame are ... – Accessed like arrays

– Base address + offset● Base address = bottom of stack● Every stack change starts fresh frame

● If offset < local frame size. there is ...– Only one way of calculating local address

base + 0, base + 4, base + 8, ...

Heap access

● Contains both array and string addresses– Array … I just did that

– String access: base+1+1+1+1+..+1● Only one way of addressing each character

Apply typing

● Type-check machine code as per paper...– Pass guarantees each address …

● Calculated same way each time– Deterministic processor– Implies same bit-pattern results each time

● Code is safe against hardware aliasing– Caused by repeatable arithmetic 'error'

– Or equivalent, such as stuck bus bit

Interesting Abstract Computer Science Things

● Formal logic of machine code ● Each instruction has many interpretations

– addiu r1 r1 4● Change stack pointer in r1 by 4● Add 4 to datum in register r1

– Disambiguated by decompilation

– Self-consistent decompilation is a proof● Decompiled instructions are proof step names

● At most 32 possible code decompilations– 32 possible register locations for stack pointer

Example

● 32B current frame

{ sp=c32!10; (10)=x } ld gp 10(sp) [get 10 gp] {sp=c32!10; (10)=gp=x}● 'c32!10' means 'pointer to 32B that ...

– has already been written to at offset 10'

● (10)=x means stack cell 10 is an x-thing● Machine code is 'ld gp 10(sp)'

– 'load reg gp from offset 10 off stack ptr'

● Decompilation/logic step is 'get 10 gp'

Uninteresting Abstract Computer Science Things

● Typing restricts the number of valid codes– In machine code, normally everything goes

– But only well-typed codes will type● There are effectively NONE in existence

– We can fix existing ones and check the fix– We can keep checking through maintenance

– Worse, only iterative sequential machine code● Makes sense to our typing system

– This is not surprising!

● Typing is theoretically double-exponential– But in practice is always instantaneous

Conclusion● Encrypted processing/KPU is what we like

– Secure!

– But it has horrible hardware aliasing ● Same address accesses different memory

● Solution for class of `damaged' processors– Resilient machine code that

● Calculates each address same way each time● Processor arithmetic `error' does not matter

– So long as it is deterministic