PathExpander: Architectural Support for Increasing the Path Coverage of

Dynamic Bug Detection

S. Lu, P. Zhou, W. Liu, Y. Zhou, J. TorrellasUniversity of Illinois at Urbana Champaign

2

Motivation

We have plenty of methods to detect software bugs– Assertions– Software (CCured, Purify)– Hardware (iWatcher)

However, these tools only check part of the total code– Only the part that is actually exercised

3

Motivation

Checking the entire code is really hard– Impossible to check all paths, or even all

branches– Too difficult to create complete test cases– State dependent on external factors

File system, system load, date etc

– Too much time required for the tools to run

We must find a way to check as much of the code as possible, with as few runs as

possible

4

PathExpander Idea

When arriving at a branch execute BOTH paths

– The Non-Taken (NT) path will not commit

A dynamic checker – NOT PathExpander – will monitor the program execution and detect bugs in any of the two paths

This can happen in Software or Hardware

– We will mainly talk about the H/W

5

PathExpander Operation

All memory operations of the NT path are sandboxed– The NT path must not permanently alter the

program’s state

The NT path may execute branches– But only the taken path will be followed– Otherwise, this can grow exponentially

6

PathExpander Operation

The NT path will be killed – If a number of instructions is normally executed

for resource contention reasons

– If an unsafe event occurs I/O, which cannot be sandboxed

– If it raises an exception load NULL, etc

The NT path can be executed on an idle core, if we have CMP processor

7

Architecture Overview

8

Basic Architecture Overview

2 4-bit exercise counters in the BTB for the two edges– An NT path will be spawned if that edge has exercise

counter below a threshold– Periodically reset to zero, to support long-running

programs

1-bit V(volatile)Tag per L1 cache line– All NT path writes set the VTag– When the NT path is squashed, invalidate these lines

9

Basic Architecture Overview

Monitor_Memory_Area: pointer to NON volatile memory, that will remain after the NT path is killed– Used by the monitoring tool

Predicate Register– Used for consistency fixes

(in a few slides…)

10

CMP Architecture Overview

NT paths are spawned to idle cores, to hide the delay

Vtag now becomes 8-bit– ID of the path that wrote in the line– Allows memory versioning

Fast register copy mechanism is required

11

CMP PathExpander Data Dependencies

12

CMP PathExpander Data Dependencies

A path must read data that it or its parents wrote.

A taken path cannot commit before– Its father commits– Its siblings have been killed

Kill siblings immediately to limit the delay if the taken path must commit to displace lines to the L2

13

State Inconsistency

Example of state inconsistency problem:

If (x >= 2) { use x; assume we have lot of data }

Else { use x; we have few data }; The predicate register will inform us if this is

a T or NT path– If we are on an NT path, we must somehow ‘fix’

these inconsistencies.

14

State Inconsistency fixing

15

State Inconsistency fixing

The compiler will insert predicated fix instructions.

If a pointer must be fixed, the compiler will have a dummy variable of the same type for the pointer to point at– Will that be correct always? What will happen if

we have unions?

16

PathExpander Implementation

Software– In PIN

Hardware– With and without CMP

4 cores for the CMP case

Dynamic Checkers– CCured (dynamic software)– iWatcher (dynamic hardware-assisted)– Assertions

NON bug-triggering inputs

17

Simulation Parameters

18

Applications Tested

19

Experimental ResultsBug Detection

Bugs Detected with NON triggering inputs

21:17 Detected to False Negatives

20

Experimental Results: Effect of Consistency Fixing on False Positives

Fixing reduces from 13:0.75 to 4:1 False to

True Positives

21

Experimental ResultsCoverage Improvement

Branch coverage increases from 40% to 65%

22

Experimental ResultsCumulative Coverage Improvement

Random InputsLast 5 Inputs are given by programmers

23

Crash- and Unsafe-Event-Latency

65% - 99% of spawned NT execute for 1000 instructions without crashing or causing unsafe events

24

Evaluation: Software Implementation Overhead

DANGER: do not attempt this at home (or during this lifetime

anyway)

25

Evaluation:Hardware Implementation Overhead

CMP overhead < 10%

If SEQ overhead small, thread spawning and squashing will worsen performance

26

Conclusion

PathExpander is NOT a dynamic checker– It simply improves coverage by checking both paths– And increases the false positives (4:1 ratio)

Software Implementation is waaaaaaaaaaay toooooooooooooooo sloooooooooooooow

27

Conclusion

A lot of things remain untouched– Where’s the tech report???– What do they do with speculative L1 lines under eviction?– Fixing is really naïve.

A lot of interesting things happen is queues, lists etc that cannot be fixed by the compiler

– What kind of ISA?

Is it worth it?

Thank you!

Questions?