On Mon, 26 Nov 2018, Tim Chen wrote: > On 11/22/2018 11:37 PM, Ingo Molnar wrote: > >> We also had that discussion with SSBD and decided that we won't chase > >> threads and send IPIs around. Yes, it's not perfect, but not the end of the > >> world either. For PRCTL it's a non issue. > > Looks like seccomp thread can be running on a remote CPU when its > TIF_SPEC_IB flag gets updated. > > I wonder if this will cause STIBP to be always off in this scenario, when > two tasks with SPEC_IB flags running on a remote CPU have STIBP bit always > *off* in SPEC MSR. > > Let's say we have tasks A and B running on a remote CPU: > > task A: SPEC_IB flag is on > > task B: SPEC_IB flag is off but is currently running on remote CPU, SPEC > MSR's STIBP bit is off > > Now arch_seccomp_spec_mitigation is called, setting SPEC_IB flag on task B. > SPEC MSR becomes out of sync with running task B's SPEC_IB flag. > > > Task B context switches to task A. Because both tasks have SPEC_IB flag > set and the flag status is unchanged, SPEC MSR's STIBP bit is not > updated. SPEC MSR STIBP bit remains off if tasks A and B are the only > tasks running on the CPU. > > There is an equivalent scenario where the SPEC MSR's STIBP bit remains on > even though both running task A and B's SPEC_IB flags are turned off. > > Wonder if I may be missing something so the above scenario is not of > concern?
The above is real. The question is whether we need to worry about it. If so, then the right thing to do is to leave thread_info.flags alone and flip the bits in a shadow storage, e.g. thread_info.spec_flags and after updating that set something like TIF_SPEC_UPDATE and evaluate that bit on context switch and if set update the TIF flags. Too tired to code that now, but it's straight forward. I'll look at it on wednesday if nobody beats me to it. Thanks, tglx