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.

1. Speculation and response
Spectre, Meltdown, XPTI, and Panopticon

2. Spectre-style flaws are the violation
of a fundamental assumption

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. 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. What is speculative execution?

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. 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. 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. How to speculation attacks
work?

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. 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. 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. False assumption #1:
Rolling back architectural state
prevents information leaks

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. False assumption #2:
“Guesses” cannot be reliably
manipulated

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. 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. 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. 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. What vulnerabilities are
currently public?

21. SP3 (“Meltdown”)
• Supervisor-level checks not done during speculation on Intel
• User-mode code can, in speculation, read supervisor-mode memory

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. 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. SP1 and Xen
• No possible mitigation (other than disabling branch prediction)
• Privileged speculation vulnerability
• As yet, no such leak(x)

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. 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. SP2 and Xen: Vulnerability
• SMEP enabled: Similar to SP1 (no known pre-existing gadgets)
• SMEP disabled: Similar to SP3 (easy to attack)

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. “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. 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. 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. Panopticon / Nothing to hide
• Get rid of the direct map
• Isolate cpu stacks
• Zero unnecessary memory
More speculation attacks? Bring it on.

33. Questions?