1. PathExpander: Architectural Support for Increasing the Path Coverage of Dynamic Bug Detection S. Lu, P. Zhou, W. Liu, Y. Zhou, J. Torrellas University of Illinois at Urbana Champaign

2. 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. 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. 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. 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. 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. 7 Architecture Overview

8. 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. 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. 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. 11 CMP PathExpander Data Dependencies

12. 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. 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. 14 State Inconsistency fixing

15. 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. 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. 17 Simulation Parameters

18. 18 Applications Tested

19. 19 Experimental Results Bug Detection Bugs Detected with NON triggering inputs 21:17 Detected to False Negatives

20. 20 Experimental Results: Effect of Consistency Fixing on False Positives Fixing reduces from 13:0.75 to 4:1 False to True Positives

21. 21 Experimental Results Coverage Improvement Branch coverage increases from 40% to 65%

22. 22 Experimental Results Cumulative Coverage Improvement Random Inputs Last 5 Inputs are given by programmers

23. 23 Crash- and Unsafe-Event-Latency 65% - 99% of spawned NT execute for 1000 instructions without crashing or causing unsafe events

24. 24 Evaluation: Software Implementation Overhead DANGER: do not attempt this at home (or during this lifetime anyway)

25. 25 Evaluation: Hardware Implementation Overhead CMP overhead < 10% If SEQ overhead small, thread spawning and squashing will worsen performance

26. 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. 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?