Low Cost Control Flow Protection Using Abstract Control

Low Cost Control Flow Protection Using Abstract Control Signatures Daya S Khudia and Scott Mahlke University of Michigan 1 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 180 nm to 16 nm (Borkar, Micro’ 05). One failure per day every chip at 16 nm (Feng et al, ASPLOS’ 10) Image credit: Certichip 2 University of Michigan Electrical Engineering and Computer Science

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

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 Correct executions Control Flow Target Errors Data Flow Errors 0% 20% 40% 60% 80% Errors in branch targets are 2. 5 x more % of runs likely to result in incorrect executions 4 University of Michigan Electrical Engineering and Computer Science 100%

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

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

Signature-Based Control Flow Checking G = G xor d 1 BB 1 s 1 d 1 = - - - G = = s 1? G = G xor d 2 G = = s 2? BB 2 s 2 d 2 = s 1 xor s 2 • 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 1 xor s 2 G = s 2 7 University of Michigan Electrical Engineering and Computer Science

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

Abstract Control Signatures • Sources of overhead G = G xor d 1 G = G xor D 2 D 1 = 0 BB 1 BB 3 • Signature updates • Signature checks G = G xor d 3 • D 1 Form = s 1 xorregions s 3 G = = s 1? • s. Abstract G== 3? G = G xor d 2 BB 4 G = G xor D 1 away the details of control flow inside a region BB 2 G = G xor d 4 D 2 = s 2 xor s 6 GG === s=? s 2? 4 BB 5 G = G xor d 5 D 3 = s 4 xor s 7 G = = s 5? 9 University of Michigan Electrical Engineering and Computer Science

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

Insight 1: Optimized updates • Signature checking C 1 = 1 C 1 = C 1 + 1 • Make sure that control flow transfer took place from a legal predecessor bb 1 bb 3 C 1 = C 1 + 1 C 1 = = 5? bb 2 C 1 = C 1 + 1 bb 4 • Check counters (path length) bb 5 • Makes sure that proper number of BBs in predecessor region were visited bb 6 C 1 = = 4? 11 University of Michigan Electrical Engineering and Computer Science

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

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

Optimization for Loops bb. N C 1 = 0 C 1 = 1 bb 2 C 1 = C 1 + 1 bb 4 C 1 = C 1 + 1 bb 2 C 1 = C 1 + 1 bb 4 C 1 = C 1 + 1 C 1 == 3? bb 3 C 1 = C 1 + 1 bb 4 C C 11 == C C 11 ++ 12 CC %== 4 == 0? 0? 1 /1 3 • 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 University of Michigan Electrical Engineering and Computer Science

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

Runtime Compilation System Overview Insert signature updates and checks Operating System Physical Hardware • Collect required program information • Analyze program structure • Insert signature updates and checks • Trigger lightweight recovery based on • selective symptoms (hardware exceptions) • signature comparison fails 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 • SPECINT 2 K Benchmarks • Statistical fault injection (SFI) experiments – GEM 5 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

CFCSS 160% CFCSS_ivl ACS + calls_rets 140% 120% 100% 80% 60% 40% 20% n Gm ea ol f 2 tw vo bz ip rte x p ga rlb 4. m k er rs pa cr af ty cf m 1. 6. gc c r vp 5. 18 0. 30 6. 25 5. 25 25 pe 25 3. 7. 19 6. 18 18 17 The performance overhead is down from 75% to 11% 17 4. gz ip 0% 16 Performance Overhead (runtime) Performance Overhead University of Michigan Electrical Engineering and Computer Science

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

Fault Detection Latency With. In 2 K Within 10 K With. In 100 K 1. 30 1. 20 1. 10 1. 00 0. 90 164. gzip 20 S AC S CS S CF AC S CS S CF AC S CS S CF AC S Fault detection latency is affected by a 175. vpr 176. gcc 181. mcf 186. crafty 197. parser 253. perl 254. gap 255. vortex 256. bzip 2 300. twolf maximum of 5% CS S CF AC CS S 0. 80 CF Normalized detection latency 1. 40 average University of Michigan Electrical Engineering and Computer Science

Conclusions • 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 21 University of Michigan Electrical Engineering and Computer Science

Thank You! Questions? 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 University of Michigan Electrical Engineering and Computer Science