Low cost control flow protection using abstract control signatures
Download
1 / 23

Low Cost Control Flow Protection Using Abstract Control Signatures - PowerPoint PPT Presentation


  • 153 Views
  • Uploaded on

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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Low Cost Control Flow Protection Using Abstract Control Signatures' - gaius


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Low cost control flow protection using abstract control signatures

Low Cost Control Flow Protection Using Abstract Control Signatures

Daya S Khudiaand Scott Mahlke

University of Michigan

1


Soft errors
Soft Errors Signatures

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)


Soft Error Detection Signatures

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


Why Control Flow Errors? Signatures

  • 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


Outline
Outline Signatures

Background

Software-based control flow checking

Abstract Control Signatures (ACS)

Experimental evaluation

Conclusions


Control Flow Checking Signatures

  • 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


Signature-Based Control Flow Checking Signatures

  • 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


Signature-Based Control Flow Checking Signatures

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


Abstract Control Signatures 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


Abstract Control Signatures 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


Insight 1: Optimized updates Signatures

  • 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


Insight 2: Optimized checks Signatures

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


Balancing Increments Signatures

  • 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


Optimization for Loops Signatures

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


Handling Call and Return SignaturesInsts

  • 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


System overview
System Overview Signatures

  • 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


Evaluation methodology
Evaluation Methodology Signatures

  • 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


Performance overhead
Performance Overhead Signatures

The performance overhead is down from 75% to 11%

18


Fault coverage
Fault Coverage Signatures

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

19


Fault detection latency
Fault Detection Latency Signatures

Fault detection latency is affected by a maximum of 5%

20


Conclusions
Conclusions Signatures

  • 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


Thank You! SignaturesQuestions?


Fault injection outcome classification
Fault Injection Outcome Classification Signatures

  • 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


ad