1 / 28

Path-aware Time-triggered Runtime Verification

Path-aware Time-triggered Runtime Verification. Samaneh Navabpour 1 , Borzoo Bonakdarpour 2 , Sebastian Fischmeister 1 1 Department of Electrical and Computer Engineering 2 School of Computer Science University of Waterloo. Runtime Verification. P rogram. Steering. Event-triggered.

katen
Download Presentation

Path-aware Time-triggered Runtime Verification

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. Path-aware Time-triggered Runtime Verification Samaneh Navabpour1, Borzoo Bonakdarpour2, Sebastian Fischmeister1 1Department of Electrical and Computer Engineering 2School of Computer Science University of Waterloo

  2. Runtime Verification Program Steering Event-triggered Verifier Observation Observer Report Runtime Verification Framework

  3. Event-triggered Monitoring • Jittery overhead • Bursts of invocations of the observer Undesirable transient overload situations in time-sensitivesystems 1 B. Bonakdarpour, S. Navabpour, and S. Fischmeister, “Sampling-based Runtime Verification”, 88-102, FM’11

  4. Alternative Monitoring Approach • Goals for the monitoring approach: • Predictablemonitoring • Bounded overhead at each intervention Candidate solution:Time-triggered Monitoring

  5. Problem of Time-triggered Monitoring • Achieving sound state reconstruction1 Sampling period = 2 Monitor m m …… Program Execution L2 L3 L4 L5 L11 L6 L1 L8 L9 L10 L7 L12 L13 L14 L15 L16 L17 L18 L19 Sample from monitor Critical instruction 1 B. Bonakdarpour, S. Navabpour, and S. Fischmeister, “Sampling-based Runtime Verification”, 88-102, FM’11

  6. Longest Sampling Period (LSP) • Longest Sampling Period (LSP)1: • is the minimum shortest path between two critical nodes A 2..4 4 Problem: redundant samples  excessive overhead D 5 1 1 1 C1 6 1. fib(int n) { 2.inti, Fnew, Fold, temp,ans; 3.Fnew= 1; Fold = 0; 4.i= 2; 5. while( i <= n ) { 6. temp = Fnew; 7.*Fnew= Fnew + Fold; 8.* Fold = temp; 9. i++; } 10.* ans = Fnew; 11. return ans;} B1 10 1 1 C2 7 B2 11 1 C3 8 LSP = 1 1 C4 9 1 B. Bonakdarpour, S. Navabpour, and S. Fischmeister, “Sampling-based Runtime Verification”, 88-102, FM’11

  7. Cause of Redundant Sampling A 2..4 path1 path2 • Using complete CFG to calculate LSP LSP = 1 4 D 5 LSPpath1 = 1 LSPpath2 = 5 1 1 1 C1 6 B1 10 Not optimal optimal 1 1 C2 7 B2 11 Path2 1 LSP 6 samples LSPpath2 1 samples C3 8 1 C4 9 84% reduction in samples

  8. Path-aware Time-triggered Monitoring A 2..4 path2 • Predict execution path • Calculate LSP using only predicted path 4 D 5 LSP = 5 1 1 1 C1 6 B1 10 Path-aware LSP (paLSP) 1 1 C2 7 B2 11 1 C3 8 1 C4 9

  9. Path Prediction Function • Predict execution path Path prediction function Problem: paLSP = LSP Implement path prediction function using symbolic execution Symbolize inputs. 3. Check path constraints. 2. Create table. Environment . . .

  10. Adaptive Path-aware Time-triggered Monitoring A 2..4 • Hypothetical execution path: path3=<path2+path1> 4 region1 D 5 LSP = 1 LSPpath3 = 1 18 samples 1 1 1 C1 6 B1 10 region2 region1 LSP= 5 1 1 7 samples C2 7 B2 11 region2 LSP= 1 1 C3 8 60% reduction in samples 1 C4 9

  11. LSP Regions • An LSP region is a set of subpathsof an execution path: • the same paLSP • each subpath is maximal • Regionalization objectives: • Reducingthe number of LSP regions • Reducingthe number of samples • Maintainingthe absolute jitter of paLSP

  12. Regionalization Algorithm W1 W2 W3 F E D C B A E E D C B A F A E B D C B A D F D C B A F E C F

  13. General Regionalization • Can have different regions for different subpaths: B C A D 5 10 15 Path 1 General Rationalization: each arc in the CFG resides in one and only one LSP region LSP = 5 LSP = 10 B A E F 2 1 5 Path 2 LSP = 1

  14. Tool Chain KLEE (Symbolic Executor) C program Symbolizer Table Compressor paLSP Calculator Variables of interest Regionalization LLVM (CFG creator)

  15. Assumptions • Limited to programs handled by KLEE • Program is sequential • Program runs on a single processor

  16. Handling KLEE Limitations • Concretization: • Extract the instruction where concretization happens • Find the node containing the instruction in CFG • Append following sub-CFG to executed path concretization … … … . . . …

  17. Handling KLEE Limitations (cont’) • Incomplete paths: • Extract the last executed instruction • Find the node containing the last executed instruction in CFG • Append following sub-CFG to executed path Last instruction … … … . . . …

  18. Reducing Table Size • Problem: • Program can have infinite execution paths. • A large table size results in large lookup overhead at runtime. • Can not reduce monitoring overhead.

  19. Reducing Table Size • KLEE patch: • extracting unique paths: • Table Compressor • Remove entries that do not improve LSP. Path with loop sequence Consecutive occurrences of Reduce consecutive occurrences to

  20. Tool Chain (cont’) • Table Compressor: • Implication Reduction: PCpath1 10 C3 C1 B1 E1 B2 Z C2 D2 D3 D4 D5 D6 D7 D8 D1 A E2 B3 10 10 10 10 1 PCpath2 paLSP = 1 20 20 20 1 20 20 PCpath3 5 5 5 5 5 5 5 5 5 5

  21. Experimental Settings • We use programs from SNU benchmark • We run the program and monitor on MCB1700 board with RTX OS • Time-triggered monitoring modes: • Fixed-LSP • Path-aware LSP • Adaptive path-aware LSP ( ) • History1 1 B. Bonakdarpour, S. Navabpour, and S. Fischmeister, “Sampling-based Runtime Verification”, 88-102, FM’11

  22. Experimental Settings (cont’) • Metrics for evaluation: • The values of the fixed LSP, paLSP, and adaptive paLSP • The number of redundant samples taken at run time by the monitor • The execution time of the monitored program. This value projects the amountof monitoring overhead

  23. Values of paLSP and Adaptive paLSP • paLSPincreases sampling period 2.4 times • Adaptive paLSP increases sampling period 3.3 times 1. More paths with sparse critical instructions Better paLSP 2. More paths with small concentration of critical instructions  Better Adaptive paLSP

  24. Redundant Samples of paLSP and Adaptive paLSP • paLSPdecreases redundant samples by 44.8% • Adaptive paLSPdecreases redundant samples by 64% 1. More paths with sparse critical instructions Less redundant samples by paLSP 2. More paths with small concentration of critical instructions  Less redundant samples by Adaptive paLSP

  25. Monitoring Overhead of paLSP and Adaptive paLSP • paLSPreduces monitoring overhead by 34% • Adaptive paLSPreduces monitoring overhead by 51% Need to keep low overhead for looking up the table at runtime. 78% reduction in redundant samples Overhead of adaptive paLSP more than paLSP

  26. Monitoring Overhead of paLSP and Adaptive paLSP with History • 66% of paLSP+historyhas less overhead than event-triggered • 75% adaptive paLSP+historyhas less overhead than event-triggered

  27. Summary • Sampling period must be devised based on execution path of the program (paLSP). • Redundant samples can be further reduced when sampling period changes dynamically at runtime (adaptive paLSP). • By merging history and paLSP or adaptive paLSP, we achieve a monitor suitable for time sensitive systems. • Predictable monitoring • Bounded overhead • Imposes less overhead than event-triggered

  28. Thank you Questions?

More Related