On Wed, Sep 7, 2022 at 10:30 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > On Sat, Sep 03, 2022 at 08:55:04PM -0700, Jim Mattson wrote: > > On Sat, Sep 3, 2022 at 8:30 PM Jim Mattson <jmattson@xxxxxxxxxx> wrote: > > > > > > On Sat, Sep 3, 2022 at 4:50 PM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > > > > [*] Not 100% true - if STIBP gets disabled by the guest, there's a small > > > > window of opportunity where the SMT sibling can help force a > > > > retbleed attack on a RET between the MSR write and the vmrun. But > > > > that's really unrealistic IMO. > > > > > > That was my concern. How big does that window have to be before a > > > cross-thread attack becomes realistic, and how do we ensure that the > > > window never gets that large? > > > > Per https://developer.amd.com/wp-content/resources/111006-B_AMD64TechnologyIndirectBranchControlExtenstion_WP_7-18Update_FNL.pdf: > > > > When this bit is set in processors that share branch prediction > > information, indirect branch predictions from sibling threads cannot > > influence the predictions of other sibling threads. > > > > It does not say that upon clearing IA32_SPEC_CTRL.STIBP, that only > > *future* branch prediction information will be shared. > > > > If all existing branch prediction information is shared when > > IA32_SPEC_CTRL.STIBP is clear, then there is no window. > > Yes, that would be an important distinction. If thread B can train the > branch predictor -- specifically targeting a retbleed attack on thread > A's RET insn (in the thunk) -- while STIBP is enabled, and then later > (when STIBP is disabled in the window before starting the guest) the > poisoned branch prediction info (BTB/BHB/whatever) suddenly becomes > visible on thread A, that makes the attack at least somewhat more > feasible. > > Note the return thunk gets untrained on kernel entry, so the attack > window is still constrained to the time between kernel entry and STIBP > disable. > > It sounds like that behavior may need clarification from AMD. If that's > possible then it might indeed make sense to move the AMD spec_ctrl wrmsr > to asm like we did for Intel. On the other side of the transition, restoration of the host IA32_SPEC_CTRL value is definitely way too late. With respect to the user/kernel boundary, AMD says, "If software chooses to toggle STIBP (e.g., set STIBP on kernel entry, and clear it on kernel exit), software should set STIBP to 1 before executing the return thunk training sequence." I assume the same requirements apply to the guest/host boundary. The return thunk training sequence is in vmenter.S, quite close to the VM-exit. On hosts without V_SPEC_CTRL, the host's IA32_SPEC_CTRL value is not restored until much later.
