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 b

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