1. Parallelizing Security Checks on Commodity Hardware Ed Nightingale Dan Peek, Peter Chen Jason Flinn Microsoft Research University of Michigan

2. Run-time security checks Provide run-time intrusion detection/prevention  Many powerful checks have been proposed  Examples: Taint-analysis, on-access virus scanning, system call graph modeling Often impose high performance penalties What makes run-time checks slow? ASPLOS 2008 2

3. Problem ASPLOS 2008 3 AA B C D Application 1)Begin application 2)Pause execution 3) Run security check Application & security check 4) Resume application PAUSE RESUME B PAUSE RESUME C PAUSE RESUME D PAUSE Checks may slow performance by 10x

4. Solution Speck (Speculative parallel check)  Parallelize checks across many cores  Provide security equivalent to sequential check Use three techniques  Transparent kernel replay system  Operating system support for speculative execution  Buffer dependent output until checks complete ASPLOS 2008 4

5. Accelerating checks with Speck ASPLOS 2008 5 A B cpu0cpu1cpu2 C cpu3 D cpu4 Speculate! 2) Execute check in parallel 1) Run process speculatively 3) Start later checks in parallel to earlier ones Speed of parallelization without sacrificing safety!

6. Outline Introduction Implementing Speck Parallelizing security checks ASPLOS 2008 6

7. Example: Executing sequentially All state ‘frozen’ and available to security check  Examples – heap, address space, file name, system call, value of a single address in memory ASPLOS 2008 7 A PAUSE

8. Example: Executing in parallel How does security check get app state? ASPLOS 2008 8 A cpu0cpu1 fork() Speck uses fork() to copy state to other core

9. fork() Example: Executing in parallel ASPLOS 2008 9 B C D cpu0 A cpu1 B epoch 0 Amortize fork by grouping checks into epochs What happens when app interacts with OS? epoch 1 fork() cpu2 E E C F F

10. Safely executing system calls Some system calls affect state of calling process  Introduces non-determinism in execution Other system calls may affect other processes  Other processes may be compromised as well Some system calls generate output  Output to screen or network cannot be undone ASPLOS 2008 10

11. Replaying non-determinism Speck replays system calls that affect process state  Some system calls (mmap) re-executed  Signal delivery limited to exit from system call Prevents instrumented clone from diverging ASPLOS 2008 11 Uninst Process Inst Clone Execute read() data OS Execute read()

12. Tracking causal dependencies Speculator [sosp05] tracks causal dependencies  Supports FIFOs, pipes, UNIX sockets etc.  Undo log associated with each object  Do not handle multi-threading (MP replay hard)  All dependent objects rolled back on failure Uninstrumented process terminated on failure Uninstrumented process can safely run ahead ASPLOS 2008 12

13. Handling output commits Problem: Some system calls create output Output to network or screen buffered When all checks within epoch complete dependent output released ASPLOS 2008 13

14. Equivalence/Safety Assume attacker cannot compromise  Speck in-kernel replay system  Speculator in-kernel causal dependency tracking Replay system ensures code equivalence  Instrumented clone does not diverge Speculator prevents permanent damage  Speculator rolls back all dependent state on failure ASPLOS 2008 14

15. Outline Introduction Implementing Speck Parallelizing security checks ASPLOS 2008 15

16. Choosing security checks All checks depend upon uninstrumented process  Amount of state determines Speck strategy  Some checks require little state or run infrequently No need for fork and replay…just pause app and ship state Some checks depend upon result of earlier check  Independent checks easy to parallelize  Many dependencies make parallelization harder  Example: taint analysis ASPLOS 2008 16

17. Using Speck to parallelize checks Process memory analysis  Sensitive data leaks System call analysis  On-access virus scanner Data flow analysis  Taint analysis ASPLOS 2008 17

18. Process Memory Analysis Checking for transient leaks of sensitive data Our check examines every memory store  Looks for signature of sensitive data  Examines all 16 byte windows around address  Use Pin dynamic binary rewriting tool Later checks do not depend on earlier checks ASPLOS 2008 18

19. MPlayer video decoding Speck 7.5x faster with 8 cores  Video plays in real time ASPLOS 2008 19

20. On-access virus scanner Scan files on-access by a process  Many different policies -- on-read on-write etc. Our check scans each file on-close  Emulates news/email server  Implemented using ClamAV libraries (180K sigs) Little state is required and checks independent  Speck does not use fork and replay for this check ASPLOS 2008 20

21. PostMark benchmark 2.8x more TPS ASPLOS 2008 21

22. Taint analysis Trace flow of data from untrusted sources  Instrument application at instruction granularity  Update map of tainted addresses at run-time  Ensure certain addresses are not tainted Later checks depend on result of earlier checks  Running in parallel cannot tell whether address was tainted during prior check ASPLOS 2008 22

23. Parallelizing taint analysis New algorithm minimizes sequential processing ASPLOS 2008 23 fork() B C D cpu0 A cpu1 A B fork() cpu2 C D …cpu n log

24. Dynamic taint compression Dependency logs were very large  Time to process longer than to run sequential check Only care about dependencies before check  Addresses and registers often overwritten  Eliminate unimportant dependencies  Reduce log size 6x ASPLOS 2008 24

25. Taint analysis: MPlayer 2x speedup on 8-cores ASPLOS 2008 25

26. Choosing a strategy ASPLOS 2008 26 CheckState required/ When required Checks independent? Fork & replay? Work to make ||? Memory analysis Memory On store Yes None Virus check File name On file close YesNoA little Taint analysis Rep. of addr space On data flow inst. NoYesA lot Fork & replay – need to attach check at fork No fork & replay – need to accept concurrent requests

27. Conclusion Run-time security checks can be slow Speck accelerates run-time checks  Parallelizing across many cores  Provides safety of executing checks sequentially ASPLOS 2008 27