CRE652 Processor Architecture Making it Trustworthy Trustworthy Computing and Branch Prediction

1. CRE652 Processor Architecture Making it Trustworthy Trustworthy Computing and Branch Prediction

2. Trusting Buggy Software Development and Installation of Computer System in general and Software in particular No Guarantee at any stage No Design Proven Correct! No Implementation Proven Bug-Free! 2

3. auth = 1 Trustworthiness in ComputingExample - SSH Communications SSH Server void do_authentication(char *user, ...) { int auth = 0; ... while (!auth) { /* Get a packet from the client */ type = packet_read(); switch (type) { ... case SSH_CMSG_AUTH_PASSWORD: if (auth_password(user, password)) auth =1; case ... } if (auth) break; } /* Perform session preparation. */ do_authenticated(…); } Session starts with Invalid Authentication 3

4. My View Difference in Program Behavior Space • Description not proven correct • w.r.t Expected • Execution with no cross-checking • w.r.t Description expected ? described ? executed

5. First Issue:Protection Measure Precision Secure (w\ false negatives) Precise Broad (insecure) (w\ false positives) set of reachable states in program execution set of secure (or certified) states captured in digest Neither nor clearly defined or known!

6. Second Issue: Semantic Gap … next: read(a); ….. assign: X := a if not_in(X, set) then goto next else goto print ; ….. print: print(whatever); ….. return • Program semantics or behavior • specified in program control and dataflow • is only in user/programmer’s mind: • Isolated instruction instance • Blinded instruction sequencing

7. Program Behavior Validation expected ? described ? Validation executed Empirical capture of {Executed Behavior} for {Expected Behavior} SW Transparent micro-architecture level validation

8. Representing Program Behaviorfrom processor’s perspective Unique ID for each dynamic instance of instruction Build up legitimate {Unique ID} empirically over time Where it comes AND where it goes AND where it is? … … … … jr $r6 … … … For control flow: • Validate at each indirect branch • Legitimacy of in-flow • Legitimacy of out-flow • at micro-architecture pc

9. Program Attribute Triplet (PAT) • PC + target + Branch History (EP) • dynamic behavior signature … jr $r3 … if (b0) then {…b1=1..} else… … If (b1) then .. else … … … jr $r6 … Unique ID PAT = (pc)||($r6)||(b1b0) pc

10. Protection via PAT Validation: Example - SSH Communications SSH Server auth = 1 void do_authentication(char *user, ...) { int auth = 0; ... while (!auth) { /* Get a packet from the client */ type = packet_read(); integer overflow switch (type) { ... case SSH_CMSG_AUTH_PASSWORD: if (auth_password(user, password)) auth =1; case ... } if (auth) break; } /* Perform session preparation. */ do_authenticated(…); } PAT = (pc|TPC|EP) Invalid!

11. Execution Path based Validation • PAT - How many? Training: Convergence in PATs {PAT} = Expected Behavior Space

12. Validation Flow in Micro-Architecture Micro-Architecture with Branch Prediction pc=branch instruction address Branch prediction global BHSR BTB its TPC next instructions with predicted target …. …. Branch verification Attack modified TPC or reached PC out of sequence Misprediction Fetch next instructions with verified target

13. Validation Flow in Micro-Architecture With Enhanced Branch Predictor for Validation pc=branch instruction address Branch prediction extend BTB with EP buffer preceding EP its TPC next instructions with predicted target …. …. hash Branch verification hash hash hash Misprediction or EP miss 1 0 “invalid” exception Bit vector Fetch next instructions with validated target Bloom Filter for PAT Ref. Yixin Shi and Gyungho Lee, “Augmenting Branch Predictor for Secure Program Execution”, Proc. the IEEE 37th Dependable Systems and Networks (DSN 2007),pp. 10 -19,June 2007

14. Validation Unit (outside to Branch Predictor) time-mux’d with H3 hash functions • estimated by a Verilog HDL implementation and a synthesis with TSMC’s 0.09um library

15. Performance Simulation 4-issue processor

16. Performance Impact (~3GHZ) 4-issue processor with EP length=8 and EP buffer =4; Bloom filter = 256kbit twice to have 8 hashes 7 ~ 8ns <2% performance overhead on average

17. Performance Overhead Order of Magnitude less than Other Approaches: CFI In-line Instrumentation (applicable for static linking only) crafty 45% gcc 10% 21% on average Program Shepherding with trace cache (w. monitoring overhead) crafty 4%(209%) gcc 625%(760%) 12%(32%) on average includes some fp benchmarks PAT validation (in HW) in SW (w. interrupt overhead) crafty 2.4% 17%(120%) gcc 0.3% 6%(24%) avg 0.9% 14%(29%) Ref. M. Abadi, et. al., “Control Flow Integrity: principles, implementations, and applications”, ACM CCS’05, 2005 Ref. V. Kriansky, et.al., “Secure Execution via program shepherding”, Proc. Usenix Security Symposium, 2002

18. Summary • Issues: • Generating {PATs} • at various stages of program development/use; • testing, compile-time flow analysis, training, etc. • Managing {PATs} • How to incorporate into program code • a part of object code; similar to PLT • What to do at invalid exception • criteria for new legitimate flow or attack; • control flow integrity policy and supporting tool • How to secure {PATs} • attack focus moves to {PATs}; • encryption and read-only Behavior Monitoring-Analysis tool System software changes {PAT} behavior proof; Public Key based DRM with support from TPM Security Policy: access control on control flow

19. Trusting Program Behavior Empirical Build-Up of Trust over time • {PATs}: Fine Grain Program Behavior Signature • Server Applications • Industrial Control System • SCADA • Embedded SW • Other Key Software • OS Kernel Signatures for Dynamic Data Flow

20. Program Counter (PC) Encoding • Encode PC-bound data at definition and decode them before de-reference at PC loading • Tight security no gap between object to be protected and protection • Little performance penalty Just one machine instruction (XOR) Checking only PC-bound • No compatibility Issue Nothing, code and memory layout, has changed • No new HW or architecture change encoding/decoding key – stack (or frame) pointer or from TSC

21. PC-encoding • Encode PC-bound variable at its definition • Decode prior to upload PC-bound variable to PC • PC-bound variables: • Return Address • Old Frame (Base) Pointer • Function Pointer • Function Pointer passed as parameter • Longjmp buffer pointer • Longjmp buffer pointer passed as parameter

22. PC-encoding: function pointer attack example … Static int (*funcptr)(..); Static char buf[BUFSIZE]; funcptr = goodfunc; /*Overflow funcptr*/ strcncpy(buf, argv[1],…); … (void)(*funcptr)(..); … Guess the address of “system()”. Add the address to the end of buf[BUFSIZE]. execl(VULPROG, VULPROG, buf,…) Code under attack – VULPROG.c Encoding Decoding The program attacker specified is NOT executed due to decoding failure

23. PC-Encoding at Linking • Explicit PC-bound variable • RET address in stack • PC-encoding at compiler • longjmp() buffer pointer • PC-encoding of return address at setjmp() • (static) function pointer • Identifying when to encode PC-bound data beyond explicit ones: e.g.Dynamic function calls trap vector table, dynamic linked library, etc.

24. PC-Encoding at (Dynamic) Linking … call lib_f … Linker 1 text … PLTf: jump *GOT[f] push offset into stack jump PLT0 2 4 shared library f …. …. GOT[f]: …. 3 lib_f: … … … … … … 5 data

25. PC-Encoding at Linking decoding … call lib_f … Linker 1 text … PLTf: jump *GOT[f] push offset into stack jump PLT0 2 encoding 4 shared library f …. …. GOT[f]: …. 3 5 lib_f: … … … … … … data

26. PC-Encoding at Linking • function pointers and function label int (*funcptr)(..); int (*funcptrcp)(..); … funcptr = goodfunc; … funcptrcp = funcptr; … (void)(*funcptr)(..); (void)(*funcptrcp)(..); … Encoding function label at linking No need of pointer variable tracking Decoding at de-referencing of function pointers at run-time

27. PC-Encoding Issues • Replay attack vulnerable Guessing encoding key, i.e. $sp (or $fp) • Recompilation needs Applicable to open source only • Unusual function pointer: • arithmetic expression e.g. static int (*funcptr)(..); static int (*anotherfuncptr)(..); … unsigned int tmp; … funcptr = goodfunc; … anotherfuncptr = funcptr + tmp + 4;

28. PC-Encoding Key desirable: • Random – no lucky guess • No Repeated sequence – no replay • Simple – no overhead NOTE: • Crypto Key - Too much overhead • Physical/natural random

29. PC-Encoding Key Time Stamp Counter • increases every cycle • non-sequential reads, i.e. no guarantee the sequence of reads before and after machine instructions Chi-Square test:

30. PC-Encoding Key Storage • Stack/frame pointer – register • Procedure specific – object header • Separate protected area • TPM and its extended memory area

31. PC-Encoding Efficacy Protection from control flow altering attacks including buffer-overflow, print format string error. e.g. Buffer Overflow; 20 different attack cases Ref. J. Wilander and M. Kamkar, “A Comparison of publicly available tools for dynamic buffer overflow protection”, Proc. Network and Distributed System Security Symp., 2003

32. PC-Encoding Efficacy • No Protection from • Impossible Path (mimicry) attacks • due to Data Corruption or unchecked trap • Trojan horse • Encoding – weak in crypto • Key – vulnerable • Trade-off btw complexity and efficacy PC-encoding provides tamper resistance to most control flow altering attempts but no protection from control flow change by un-trusted software or compromised data induced impossible path

33. PC-Encoding: Performance effects • Program Counter Encoding with gcc andrecompiled Linux Overhead (%) = 100* nic/IC, where nic is the instruction count with the extra instructions added for PC-Encoding, and IC is the instruction count without PC-encoding (all instruction counts are dynamic). Apache Web Server Performance with and without PC-Encoding

34. Architecture Support for PC-Encoding • Instruction extension: • Incorporate encoding/decoding into store/load • Incorporate decoding into indirect branch • e.g. • key-register $key • pc-store $n, $m(c); Mem[($m) + c] := ($n) xor ($key); • pc-load $n, $m(c); $n := (Mem[($m) + c]) xor ($key); • decode-&-jmp $n; pc:= ($n) xor ($key) mov #goodfunc, funcptr mov funcptr, funcptrcp … mov funcptr, $r1 dec-&-jmp $r1 … mov funcptrcp, $r2 dec-&-jmp $r2 int (*funcptr)(..); int (*funcptrcp)(..); funcptr = goodfunc; funcptrcp = funcptr; … (void)(*funcptr)(..); … (void)(*funcptrcp)(..); …