View
217
Download
0
Tags:
Embed Size (px)
Citation preview
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?