On Mon, Oct 3, 2022 at 11:56 AM Tom Lendacky <thomas.lendacky@xxxxxxx> wrote: > > On 9/8/22 00:30, Josh Poimboeuf 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. > > Sorry, just saw this thread... > > Any predictions made while STIBP is enabled are local to the thread > creating them. When STIBP is cleared, newly created predictions would be > shared between thread A and thread B, but old/existing predictions from > Thread B that were created while STIBP was enabled, wouldn't be used in > thread A. The original question was about the following scenario: One thread is in the host kernel, processing a #VMEXIT. The other thread is in the guest. Initially, the host kernel thread has STIBP enabled, and the guest thread does not. All is well. In preparation for returning to the guest, the host kernel thread loads the guest's SPEC_CTRL value, which has STIBP clear. It does this well in advance of the next VMRUN, the way the code is written today. At this point, the guest thread can create shared predictions. How quickly can it do so? Is it quick enough that we should worry about the fact that the host kernel thread still has RET instructions to execute before the next VMRUN?
