Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

XPDDS18: Speculation and Response: Spectre, Meltdown, XPTI, and Panopticon - George Dunlap, Citrix

136 views

Published on

Spectre and Meltdown were issues disclosed at the beginning of this year. Unlike previous bugs, they represent not simple mistakes, but the failure of a fundamental assumption that processor designers have been making for years.

This talk will briefly give an overview of speculation, and how the Spectre and Meltdown attacks work at a high level. It will then give an analysis of how difficult these vulnerabilities are to exploit in Xen, and how the various mitigations work. Finally, I'll describe what I've been calling Panopticon, an approach that should be able to mitigate the worst effects of any future speculation bug.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

XPDDS18: Speculation and Response: Spectre, Meltdown, XPTI, and Panopticon - George Dunlap, Citrix

  1. 1. Speculation and response Spectre, Meltdown, XPTI, and Panopticon
  2. 2. Spectre-style flaws are the violation of a fundamental assumption
  3. 3. Goals • Help you understand Specter-Style vulnerabilities • Understand how vulnerable Xen is (or isn’t) • Understand the available mitigations and when to use them
  4. 4. Outline • What is speculative execution? • How do the speculative execution vulnerabilities work? • Details about the specific vulnerabilities • How difficult they are to execute in practice • “Panopticon”
  5. 5. What is speculative execution?
  6. 6. What is speculative execution? • Speculate: To guess • Execution: to do something • Speculative execution: Doing something based on a guess • Something we do in real life
  7. 7. Instruction-level parallelism (ILP) • Modern processors give the illusion of one instruction happening at a time • But in fact, the processor tries to do as many instructions in parallel as possible
  8. 8. ILP, continued • But sometimes, operations or execution depends on the result of a long calculation • Speculate: • Guess which way the operation will turn out • Execute based on the guess • Roll back if the guess turns wrong • Hundreds or thousands of instructions deep
  9. 9. How to speculation attacks work?
  10. 10. Alternate universes • Imagine you have a device with a button • Pressing the button forks off a temporary alternate universe • For the next 30 seconds everything you do succeeds • After that, the alternate universe disappears and you go back to when you started, remembering nothing
  11. 11. Alternate universes • Not very useful… unless things that happen in the alternate universe can affect the real one • Imagine that the heat of objects “leaked” back into the real universe
  12. 12. Template speculative attack result = 0; for (bit = 0; bit < 8; bit++) { evict_cacheline(A) if ( fork_alternate_universe() ) { if ( (*target_address) & (1 << bit)) load_cacheline(A) } if (cacheline_loaded(A)) result |= (1 << bit); }
  13. 13. False assumption #1: Rolling back architectural state prevents information leaks
  14. 14. Speculation roll-back • Rolls back architectural state • Memory, registers, etc • Doesn’t roll back other state • caches, TLB state, &c • This state can be both manipulated and detected
  15. 15. False assumption #2: “Guesses” cannot be reliably manipulated
  16. 16. Requirements for an attack • Speculation that can be reliably manipulated • A “gadget” that can (in speculation) be induced to reliably read privileged information and leak it
  17. 17. Two types of speculative vulnerability • Unprivileged speculation • Allowing unprivileged code in speculation access it should never have • Attacker can supply their own “leaky gadget” • Privileged speculation • Allow speculation to cause privileged code to do something it would never do otherwise • Requires a pre-existing “leaky gadget”, or dynamic code generation
  18. 18. Privileged gadgets • “Dynamic code generation”: • Attacker can cause their own privileged leaky gadget to be created in speculation • No pre-existing gadgets have yet been discovered • All “privileged speculation” proof of concepts have used eBPF • No JIT, (probably) not vulnerable to privileged speculation
  19. 19. What kinds of things can be leaked? • SP1-4: Content of mapped memory • Xen currently maps all host memory • Successful attacks on Xen can read arbitrary host memory • Lazy FPU: Contents of another domain’s FPU / XSAVE state • XSAVE state often contains cryptographic key material and derivatives
  20. 20. What vulnerabilities are currently public?
  21. 21. SP3 (“Meltdown”) • Supervisor-level checks not done during speculation on Intel • User-mode code can, in speculation, read supervisor-mode memory
  22. 22. SP3 and Xen • HVM guests not in the same address space as Xen • PV guests in the same address space as Xen • XPTI: Remove all hypervisor mappings when switching into a PV guest
  23. 23. SP1 (Spectre variant 1) • “Bounds bypass” if ( i < BUFSIZE ) { x = buf[i]; leak(x); } • Attack: Manipulate branch predictor • During speculation, i can be an arbitrary value, which means buf[i] will be an address of the attacker’s choice
  24. 24. SP1 and Xen • No possible mitigation (other than disabling branch prediction) • Privileged speculation vulnerability • As yet, no such leak(x)
  25. 25. SP2 (with SMEP / without SMEP) • “Branch target injection” • “Branch target buffer”: FROM will jump to TO • Only 1st 12 bits of FROM stored [f = ATTACKER_TARGET] x=*(ATTACKER_ADDRESS) *f(...) ... ATTACKER_ADDRESS: leak(x)
  26. 26. SP2 (with SMEP / without SMEP) [f = ATTACKER_TARGET] x=*(ATTACKER_ADDRESS) *f(...) ... ATTACKER_ADDRESS: leak(x) • With SMEP: ATTACKER_TARGET must be privileged (need pre-existing gadget) • Without SMEP: ATTACKER_TARGET can be user-mode (attacker can supply gadget)
  27. 27. SP2 and Xen: Vulnerability • SMEP enabled: Similar to SP1 (no known pre-existing gadgets) • SMEP disabled: Similar to SP3 (easy to attack)
  28. 28. SP2 and Xen: Mitigations • Mitgation 1: Flush branch target buffers • Erase “poisoned” branch buffers • New instructions (microcode) required • Mitigation 2: Retpoline • Trick processor into not using BTB • Compiler support for thunking required
  29. 29. “Privileged speculation” and Xen • No dynamic code generation • Pre-existing gadgets? • None found so far • Probably a matter of number of lines of code
  30. 30. Further mitigation • Xen maps all of host memory… but why? • Nothing more than convenience • “Map on demand” still necessary for host with over 5TiB of memory • Still present, and tested in debug mode
  31. 31. Panopticon / Nothing to hide • Panopticon: A conceptual prison where the prisoners had to assume they were being watched at all times • Can we build Xen with the assumption that guests can read any memory it has mapped at any time?
  32. 32. Panopticon / Nothing to hide • Get rid of the direct map • Isolate cpu stacks • Zero unnecessary memory More speculation attacks? Bring it on.
  33. 33. Questions?

×