0

Can speculative execution cause an Extended Page Table (EPT) violation on x86 processors?

Assume I want to access a structure that has different Guest Physical Address (GPA) to Host Physical Address (HPA) mappings in two different EPTs. This structure is supposed to be accessible only if, lets say EPT #2 is active in the VMM. The guest OS is paravirtualized, and we utilize the vmfunc instruction for the EPT switch.

; Switch to EPT #2
mov    $0x2, %rcx
mov    $0x0, %rax
vmfunc
; Access structure (read)
mov    (%rdx), %rbx
; Do something with %rbx
; ...
; Switch back to EPT #1
mov    $0x1, %rcx
mov    $0x0, %rax
vmfunc

Could speculative execution cause an EPT violation if the mov instruction is executed before the first vmfunc instruction? Or does vmfunc act as a "fence" and prohibits any speculative execution or out-of-order execution in general?

CRoemheld
  • 889
  • 7
  • 26
  • Do you mean Meltdown-style speculative violation? Other than timing / cache side-channels, the CPU does preserve the illusion of executing one instruction at a time, in program order. If it does any speculation past something that might change the validity of later instructions, it has to be prepared to roll it back. (e.g. branch mispredicts, memory order mis-speculation machine clears.) – Peter Cordes Mar 25 '22 at 16:20
  • It might be similar to it. However, I don't exactly get the "rolling back" part. While it is true that some results or operations need to be "undone", this doesn't exactly work with a signal that has already been sent (e.g. EPT violation). So as soon as the instruction would trigger the exception while in speculative execution, rolling back wouldn't really work anymore AFAIK. Or am I misunderstanding something? – CRoemheld Mar 26 '22 at 14:45
  • 1
    Speculative execution of an instruction that would fault (like a load from a bad pointer which would #PF normal page fault, or some kind of EPT fault, or a div by zero) doesn't actually raise that exception until / unless the instruction becomes non-speculative by reaching retirement from the ROB. That can only happen after all previous instructions are also confirmed to be non-speculative: in-order retirement allows precise exceptions. See [Why CPU speculative execution does not cause OOB program crash?](https://stackoverflow.com/q/48136276) – Peter Cordes Mar 26 '22 at 18:47
  • 1
    Likely the CPU simply doesn't speculate past `vmfunc`, since current designs don't rename the privilege level or CR3 (the page table pointer). (i.e. they don't speculate into interrupt / exception handlers, or past a mov to CR3). But if a CPU wanted to speculate past that, it would have to maintain correctness. (Stores to individual PTEs aren't as strongly ordered wrt. loads/stores that could speculatively use them, though, see https://www.felixcloutier.com/x86/invlpg and https://blog.stuffedcow.net/2015/08/pagewalk-coherence/) – Peter Cordes Mar 26 '22 at 18:52
  • Thank you for the explanation, the part about the CPU not raising the exception until after the instruction becomes non-speculative makes it understandable. – CRoemheld Mar 27 '22 at 13:57

0 Answers0