3 ms·
Are the timing semantics within a virtual environment predictable enough to pull off the attack within the limits of the guest context? I guess at this point we
by cookiecaper 9y ago
Are the timing semantics within a virtual environment predictable enough to pull off the attack within the limits of the guest context? I guess at this point we could just test for ourselves.
EDIT: Actually, thinking about this some more ... if the host has retpoline and the microcode update, the indirect jump technique can't be used to deduce the state of the BHB, so the kernel addresses never leak. If KVM's _internal_ kernel space, which isn't actually protected by the CPU's ring 0 (I think, unless this is also provided by VT-x?), is guarded by whichever of IBRS/IBPB is relevant, then would those mitigations prevent guest exploitation as well regardless of timing semantics?
- deleted 9y ago[deleted]
- comex 9y agoThe mitigations you mentioned are all for Spectre, aka variants 1 and 2, aka tricking code running in kernel mode into doing something weird. But KPTI is specifically for Meltdown, aka variant 3, aka having user mode code speculatively access kernel data directly (data which is mapped in its address space but marked kernel-only - thus the ‘fix’ is to separate the address spaces). Protecting kernel code with retpolines or by flushing the branch predictor won’t help with Meltdown, because it doesn’t rely on kernel code at all.