1 / 23

Low Cost Control Flow Protection Using Abstract Control Signatures

Low Cost Control Flow Protection Using Abstract Control Signatures. Daya S Khudia and Scott Mahlke. University of Michigan. Soft Errors. Image credit: Certichip. Soft errors, also called single-event upsets(SEUs) Occur because of High energy particle strikes or electrical noise

gaius
Download Presentation

Low Cost Control Flow Protection Using Abstract Control Signatures

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Low Cost Control Flow Protection Using Abstract Control Signatures Daya S Khudiaand Scott Mahlke University of Michigan 1

  2. Soft Errors Image credit: Certichip • 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)

  3. Soft Error Detection Control flow Data flow DMR, TMR DMR, TMR ~100-200% Instruction duplication + hardware symptoms (Shoestring, profileBased) Signature/assertion based (CFCSS, ACFC) Instruction duplication (SWIFT, EDDI) Increasing Overhead ~30-70% ~10-30% Target Solution • 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 • Traditional dual/triple – modular redundancy • Mission-critical reliability • Software-based control flow protection • Usually by embedding signatures/assertions in basic blocks • Combine duplication and symptoms • Improved by using profiling 3

  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 4

  5. Outline Background Software-based control flow checking Abstract Control Signatures (ACS) Experimental evaluation Conclusions

  6. Control Flow Checking • 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 BB1 update sig var check sig var BB2 update sig var check sig var 6

  7. Signature-Based Control Flow Checking • 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 s1 BB1 G = G xor d1 d1 = - - - G = = s1? s2 BB2 G = G xor d2 d2 = s1xor s2 G = = s2? G = G xor d2 G = s1xor s1xor s2 G = s2 7

  8. Signature-Based Control Flow Checking s1 d1 = - - - BB1 G = G xor d1 G = G xor D2 D1 = 0 s3 d3 = s-xor s3 BB3 G = G xor d3 D1 = s1xor s3 G = = s1? G = = s3? BB2 G = G xor d2 G = G xor D1 • For branch fan-in nodes • Extra updates • Dynamically adjusting signature are required s2 d2 = s1xor s2 G = = s2? 8

  9. Abstract Control Signatures • Sources of overhead • Signature updates • Signature checks BB1 G = G xor d1 G = G xor D2 D1 = 0 BB3 • Form regions • Abstract away the details of control flow inside a region G = G xor d3 D1 = s1xor s3 G = = s1? G = = s3? BB2 G = G xor d2 G = G xor D1 BB4 BB5 G = = s2? G = G xor d4 D2 = s2xor s6 G = G xor d5 D3 = s4xor s7 G = = s5? G = = s4? 9

  10. Abstract Control Signatures • Sources of overhead • Signature updates • Signature checks BB1 G = G xor d1 G = G xor D2 D1 = 0 Sig update BB3 G = G xor d3 D1 = s1xor s3 Sig update G = = s1? G = = s3? BB2 G = G xor d2 G = G xor D1 • Form regions • Abstract away the details of control flow inside a region Sig update G = = s2? • Optimize signature updates • check simple run-time properties BB4 G = G xor d4 D2 = s2xor s6 Sig update Sig check G = = s4? • Optimize checks • Insert checks at region boundaries BB5 G = G xor d3 D3 = s4xor s7 Sig update G = = s5? 10

  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 C1 = C1 + 1 C1 = 1 bb2 bb4 bb3 C1 = C1 + 1 C1 = C1 + 1 bb5 C1 = C1 + 1 bb6 C1 = C1 + 1 C1 = = 5? C1 = = 4? 11

  12. Insight 2: Optimized checks Interval 1 Interval 2 • 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 bb_latch1 bb1 bb2 bb3 bb4 bb_latch2 12

  13. Balancing Increments • Naively inserting checks • Multiple counter value checks would be required at exits bb1 C1 = C1 + 1 C1 = 1 Insert extra increment along these edges bb2 bb3 C1 = C1 + 1 C1 = C1 + 1 • Developed an algorithm to get (details are in paper) • increment edges • increment amounts bb4 C1 = C1 + 1 C1 = C1 + 1 bb5 C1 = C1 + 1 C1 = = 5? C1 = = 3 or 4? C1 = = 4 or 5? C1 = = 5? 13

  14. Optimization for Loops bbN bb1 bb1 C1 = 1 C1 = C1 + 1 C1 = C1 + 1 C1 = 0 bb2 bb4 bb2 bb3 C1 = C1 + 1 C1 = C1 + 1 C1 = C1 + 1 bb4 bb4 C1 = C1 + 1 C1 = C1 + 1 C1 = C1 + 2 C1 == 3? C1 / 3 == 0? C1 % 4 == 0? • 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

  15. Handling Call and Return Insts • 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 Ret_BB inverse update sig var return; call foo; foo: Entry_BB update sig var with call specific length call foo; Inverse update with call specific length update sig var check sig var 15

  16. System Overview • Collect required program information • Analyze program structure • Insert signature updates and checks Compilation Insert signature updates and checks Operating System • Trigger lightweight recovery based on • selective symptoms (hardware exceptions) • signature comparison fails Runtime Physical Hardware

  17. Evaluation Methodology • Program analysisand 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

  18. Performance Overhead The performance overhead is down from 75% to 11% 18

  19. Fault Coverage On average, fault coverage of ACS is comparable to CFCSS with almost 7x reduction in overhead 19

  20. Fault Detection Latency Fault detection latency is affected by a maximum of 5% 20

  21. 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

  22. Thank You!Questions?

  23. 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

More Related