On Fri, Sep 02, 2022 at 12:35:13PM -0700, Jim Mattson wrote: > On Fri, Sep 2, 2022 at 12:14 PM Pawan Gupta <pawan.kumar.gupta@xxxxxxxxx> wrote: > > > It may be possible to use shared BHB to influence the choice of indirect > > targets, but there are other requirements that needs to be satisfied > > such as: > > - Finding a disclosure gadget. > > Gadgets abound, and there are tools to find them, if the attacker has > the victim binary. Agree. > > - Controlling register inputs to the gadget. > > This is non-trivial, since kvm clears GPRs on VM-exit. However, an > attacker can look for calls to kvm_read_register() or similar places > where kvm loads elements of guest state. The instruction emulator and > local APIC emulation both seem like promising targets. Those "elements of guest state" needs to also survive till the desired indirect-branch site, it could be possible. > > - Injecting the disclosure gadget in the predictors before it can be > > transiently executed. > > IIUC, the gadget has to already be an indirect branch target that can > be exercised by some guest action (e.g. writing to a specific x2APIC > MSR). Is that correct? That is correct. > > - Finding an appropriate indirect-branch site after VM-exit, and before > > BHB is overwritten. > > Is it the case that the RIP of the victim indirect branch has to alias > to the RIP of the "training branch" above in the predictors? No, its due to collision in history based predictors that account for branch history + RIP. > Presumably, guest influence diminishes after every branch, even before > the BHB is completely overwritten. That is true, with every taken-branch the guest control diminishes. Thanks, Pawan
