University of Michigan Electrical Engineering and Computer Science 1 Low Cost Control Flow Protection Using Abstract Control Signatures Daya S Khudia and Scott Mahlke University of Michigan

Electrical Engineering and Computer Science Soft Errors Soft errors, also called single-event upsets(SEUs) –Occur because of High energy particle strikes or electrical noise Parameters affecting soft error rates –Shrinking dimensions, Voltage scaling 100 times increase from 180nm to 16nm (Borkar, Micro’05). One failure per day every chip at 16nm (Feng et al, ASPLOS’10) Image credit: Certichip 2

University of Michigan Electrical Engineering and Computer Science  Redundant execution in a single-threaded context  Compiler interleaves original and redundant instructions  Our target is a low-overhead control flow protection solution  Comparable coverage  Software-based control flow protection  Usually by embedding signatures/assertions in basic blocks  Combine duplication and symptoms  Improved by using profiling  Traditional dual/triple – modular redundancy  Mission-critical reliability 3 Soft Error Detection DMR, TMR Signature/assertion based (CFCSS, ACFC) Target Solution Increasing Overhead Data flow Control flow DMR, TMR Instruction duplication (SWIFT, EDDI) Instruction duplication + hardware symptoms (Shoestring, profileBased) ~ % ~30-70% ~10-30%

University of Michigan Electrical Engineering and Computer Science 4 Why Control Flow Errors? More than 70% of the transient faults lead to control flow errors (Vahdatpour et al.) Faults in hardware components manifest as control flow errors Program counter Address circuitry Errors in branch targets are 2.5x more likely to result in incorrect executions

University of Michigan Electrical Engineering and Computer Science 5 Outline Background Software-based control flow checking Abstract Control Signatures (ACS) Experimental evaluation Conclusions

University of Michigan Electrical Engineering and Computer Science 6 Control Flow Checking update sig var BB1 check sig var BB2 update sig var check sig var Two steps for control flow checking Compute signature at runtime Compare with an expected correct value In case of illegal control flow transfer, the signature check fails

University of Michigan Electrical Engineering and Computer Science 7 Signature-Based Control Flow Checking G = G xor d 1 BB1 s1s1 G = = s 1 ? s2s2 BB2 Software-based control flow checking Update signature in each basic block Check signature in each basic block Can only handle errors in branch targets Errors in branch directions (conditions) are not covered G = G xor d 2 G = = s 2 ? G = G xor d 2 G = s 1 xor s 1 xor s 2 G = s 2 d 1 = d 2 = s 1 xor s 2

University of Michigan Electrical Engineering and Computer Science 8 Signature-Based Control Flow Checking s 1 d 1 = G = = s 2 ? G = = s 1 ? s 2 d 2 = s 1 xor s 2 s 3 d 3 = s - xor s 3 G = G xor d 3 D 1 = s 1 xor s 3 G = = s 3 ? G = G xor d 2 G = G xor D 1 For branch fan-in nodes Extra updates Dynamically adjusting signature are required BB1 BB2 BB3 G = G xor d 1 G = G xor D 2 D 1 = 0

University of Michigan Electrical Engineering and Computer Science G = = s 2 ? G = = s 1 ? G = G xor d 3 D 1 = s 1 xor s 3 G = = s 3 ? G = G xor d 2 G = G xor D 1 BB1 BB2 BB3 G = G xor d 1 G = G xor D 2 D 1 = 0 Form regions Abstract away the details of control flow inside a region 9 Abstract Control Signatures G = G xor d 4 D 2 = s 2 xor s 6 G = = s 4 ? BB4 G = G xor d 5 D 3 = s 4 xor s 7 G = = s 5 ? BB5 Sources of overhead Signature updates Signature checks

University of Michigan Electrical Engineering and Computer Science G = G xor d 3 D 3 = s 4 xor s 7 10 Abstract Control Signatures G = = s 2 ? G = = s 1 ? G = G xor d 3 D 1 = s 1 xor s 3 G = = s 3 ? G = G xor d 2 G = G xor D 1 BB1 BB2 BB3 G = G xor d 1 G = G xor D 2 D 1 = 0 Sig update G = G xor d 4 D 2 = s 2 xor s 6 G = = s 4 ? BB4 G = = s 5 ? BB5 Sig update Optimize signature updates check simple run-time properties Sources of overhead Signature updates Signature checks Optimize checks Insert checks at region boundaries Form regions Abstract away the details of control flow inside a region Sig check

University of Michigan Electrical Engineering and Computer Science 11 Insight 1: Optimized updates Signature checking Make sure that control flow transfer took place from a legal predecessor Check counters (path length) Makes sure that proper number of BBs in predecessor region were visited bb1 C 1 = 1 C 1 = C bb2 bb3 bb5 bb6 C 1 = C bb4 C 1 = C C 1 = = 4?C 1 = = 5?

University of Michigan Electrical Engineering and Computer Science 12 Insight 2: Optimized checks Sufficient to have a single check for a group of basic blocks Requirement on regions The header block of a region should dominate all the BBs in that region (single entry point) Nested loops should not be contained in a region bb1bb_latch1 Interval 1Interval 2 bb2 bb4 bb3 bb_latch2

University of Michigan Electrical Engineering and Computer Science 13 Balancing Increments bb1 C 1 = 1 C 1 = C C 1 = = 3 or 4? Naively inserting checks Multiple counter value checks would be required at exits Insert extra increment along these edges C 1 = = 5? C 1 = = 4 or 5? C 1 = = 5? Developed an algorithm to get (details are in paper) increment edges increment amounts bb2 bb3 bb4 bb5 C 1 = C 1 + 1

University of Michigan Electrical Engineering and Computer Science bbN bb2 Move checks out of the loop Insert increments Such that counter value is a power of two (facilitates remainder operation instead of costly division) 14 Optimization for Loops bb1 C 1 = 1 C 1 = C C 1 = 0 C 1 / 3 == 0? C 1 == 3? bb4 C 1 = C bb1 bb2 bb3 bb4 C 1 = C C 1 = C C 1 % 4 == 0?

University of Michigan Electrical Engineering and Computer Science 15 Handling Call and Return Insts update sig var with call specific length inverse update sig var Ret_BB return; foo: call foo; Inverse update with call specific length check sig var update sig var Entry_BB call foo; Every function in the program is assigned a unique path length Global Signature variable is Updated before and inversely updated after call Inversely updated and updated inside callee

University of Michigan Electrical Engineering and Computer Science System Overview Insert signature updates and checks Collect required program information Analyze program structure Insert signature updates and checks Operating System Physical Hardware Trigger lightweight recovery based on selective symptoms (hardware exceptions) signature comparison fails Runtime Compilation 16

University of Michigan Electrical Engineering and Computer Science Evaluation Methodology Program analysis and signatures updates/checks –Implemented as compiler pass in the LLVM compiler SPECINT2K Benchmarks Statistical fault injection (SFI) experiments –GEM5 simulator in ARM syscall emulation mode Random (single) bit flip in control flow target –Simulated entire benchmarks after fault injection –Log files analyzed for results classification 17

University of Michigan Electrical Engineering and Computer Science Performance Overhead 18 The performance overhead is down from 75% to 11%

University of Michigan Electrical Engineering and Computer Science Fault Coverage 19 On average, fault coverage of ACS is comparable to CFCSS with almost 7x reduction in overhead

University of Michigan Electrical Engineering and Computer Science Fault Detection Latency 20 Fault detection latency is affected by a maximum of 5%

University of Michigan Electrical Engineering and Computer Science Conclusions 21 We propose Abstract Control Signatures (ACS) –Signature checking at coarse-grain –Simplified signature updates In comparison to a traditional signature based scheme (CFCSS) –Reduces performance overhead from 75% down to 11% –Fault coverage is comparable

University of Michigan Electrical Engineering and Computer Science 22

University of Michigan Electrical Engineering and Computer Science Fault Injection Outcome Classification Masked –No corruption in the program output CFDetects –Detected by control flow checking Covered by symptoms (HWDetects) –Produces a symptom such as page fault in 2000 cycles of fault injection Failures –Fail status on program termination or infinite loop. SDCs (Silent Data Corruptions) –Fault injections which results in user visible corruptions 23