3 ms·

Is there a real reason to set `pti=on` in virtualized kernels, other than an abundance of caution? I'm not familiar with the internals of VT-x or intel-kvm.ko,

Is there a real reason to set `pti=on` in virtualized kernels, other than an abundance of caution? I'm not familiar with the internals of VT-x or intel-kvm.ko, but as far as I know, this is just doubling the hit for no real reason (unless you're doing nKVM or similar?).

zaroth 9y ago
I have this question as well. I can understand docker containers being vulnerable to other containers reading kernel memory across the boundary, but with VMs you would have to read into an entirely different kernel, right? I can understand how the attack works for JavaScript to read from the parent process / I.e. steal session cookies, but how could this attack work across VM boundaries?
- cookiecaper 9y ago
  The Project Zero article [0] demonstrates breaking KVM this way by using indirect jumps to deduce the state of the CPU's internal branch history buffer: >The branch history buffer state is leaked in steps of 2 bits by measuring misprediction rates of an indirect call with two targets. That leaks out the physical address of the KVM driver, against which more code is speculative executed, with side channel being used to make these results deducible within the guest's memory area. Technically speaking, the guest can't fully unsandbox (i.e., they can't run commands on the physical host OS) with Spectre/Meltdown alone, but they can read the memory content of the entire physical host in the case of Meltdown, or all of userspace in the case of a Meltdown-less Spectre. This is being mitigated by retpoline + microcode update + new kernel parameters IBRS and IBPB, which will make it so that users can't mislead the CPU with speculative indirection (by killing the functionality in risky situations, another layer of slowdowns we will all have to confront soon; impact is not seen until major distros recompile everything with retpoline). PTI itself wouldn't mitigate that leakage, it just mitigates its exploitation to read back the host memory. However, this is a hardware thing that affects the host OS. If the host already has these features enabled on the real kernel, what value do they provide within the guest itself? Is timing _within the guest kernel_ accurate enough for sandboxed exploitation, making this a universal sandbox-constrained privilege escalation? I don't know. It'd be nice to avoid the redundant overhead, of course. [0] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...
loeg 9y ago
Do you expect privilege isolation between users and kernel in your virtualized environment? If so, you have to enable PTI. If your virtualized environment just has a single root user, there's no need.
- 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 ago
    The 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.

zaroth 9y ago

I have this question as well. I can understand docker containers being vulnerable to other containers reading kernel memory across the boundary, but with VMs you would have to read into an entirely different kernel, right? I can understand how the attack works for JavaScript to read from the parent process / I.e. steal session cookies, but how could this attack work across VM boundaries?

cookiecaper 9y ago
The Project Zero article [0] demonstrates breaking KVM this way by using indirect jumps to deduce the state of the CPU's internal branch history buffer: >The branch history buffer state is leaked in steps of 2 bits by measuring misprediction rates of an indirect call with two targets. That leaks out the physical address of the KVM driver, against which more code is speculative executed, with side channel being used to make these results deducible within the guest's memory area. Technically speaking, the guest can't fully unsandbox (i.e., they can't run commands on the physical host OS) with Spectre/Meltdown alone, but they can read the memory content of the entire physical host in the case of Meltdown, or all of userspace in the case of a Meltdown-less Spectre. This is being mitigated by retpoline + microcode update + new kernel parameters IBRS and IBPB, which will make it so that users can't mislead the CPU with speculative indirection (by killing the functionality in risky situations, another layer of slowdowns we will all have to confront soon; impact is not seen until major distros recompile everything with retpoline). PTI itself wouldn't mitigate that leakage, it just mitigates its exploitation to read back the host memory. However, this is a hardware thing that affects the host OS. If the host already has these features enabled on the real kernel, what value do they provide within the guest itself? Is timing _within the guest kernel_ accurate enough for sandboxed exploitation, making this a universal sandbox-constrained privilege escalation? I don't know. It'd be nice to avoid the redundant overhead, of course. [0] https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html https://googleprojectzero.blogspot.com/2018/01/reading-privi...

loeg 9y ago

Do you expect privilege isolation between users and kernel in your virtualized environment? If so, you have to enable PTI. If your virtualized environment just has a single root user, there's no need.

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 ago
  The 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.