1 / 27

Parallelizing Security Checks on Commodity Hardware

Parallelizing Security Checks on Commodity Hardware. Ed Nightingale Dan Peek, Peter Chen Jason Flinn Microsoft Research University of Michigan. Run-time security checks. Provide run-time intrusion detection/prevention Many powerful checks have been proposed

flann
Download Presentation

Parallelizing Security Checks on Commodity Hardware

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. Parallelizing Security Checks on Commodity Hardware Ed Nightingale Dan Peek, Peter Chen Jason FlinnMicrosoft 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

  3. Problem Application & security check Application A A Begin application PAUSE B Pause execution 3) Run security check C 4) Resume application RESUME D B PAUSE RESUME C PAUSE RESUME D PAUSE ASPLOS 2008 • 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

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

  6. Outline Introduction Implementing Speck Parallelizing security checks ASPLOS 2008

  7. Example: Executing sequentially A PAUSE • 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

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

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

  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

  11. Replaying non-determinism data data Inst Clone UninstProcess Execute read() Execute read() OS • 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

  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

  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

  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

  15. Outline Introduction Implementing Speck Parallelizing security checks ASPLOS 2008

  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

  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

  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

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

  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

  21. PostMark benchmark 2.8x more TPS ASPLOS 2008

  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

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

  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

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

  26. Choosing a strategy • Fork & replay – need to attach check at fork • No fork & replay – need to accept concurrent requests ASPLOS 2008

  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

More Related