On Wed, Nov 13, 2024 at 05:55:05PM -0800, Pawan Gupta wrote: > > > user->user SpectreRSB is also mitigated by IBPB, so RSB filling is > > > unnecessary when IBPB is issued. Also, when an appication does not opted-in > > > for IBPB at context switch, spectre-v2 for that app is not mitigated, > > > filling RSB is only a half measure in that case. > > > > > > Is RSB filling really serving any purpose for userspace? > > > > Indeed... > > > > If we don't need to flush RSB for user->user, we'd only need to worry > > about protecting the kernel. Something like so? > > > > - eIBRS+!PBRSB: no flush > > - eIBRS+PBRSB: lite flush > > Yes for VMexit, but not at kernel entry. PBRSB requires an unbalanced RET, > and it is only a problem until the first retired CALL. At VMexit we do have > unbalanced RET but not at kernel entry. > > > - everything else: full flush > > > i.e., same logic as spectre_v2_determine_rsb_fill_type_at_vmexit(), but > > also for context switches. > > Yes, assuming you mean user->kernel switch, and not process context switch. Actually I did mean context switch. AFAIK we don't need to flush RSB at kernel entry. If user->user RSB is already mitigated by IBPB, then at context switch we only have to worry about user->kernel. e.g., if 'next' has more (in kernel) RETs then 'prev' had (in kernel) CALLs, the user could trigger RSB underflow or corruption inside the kernel after the context switch. Doesn't eIBRS already protect against that? For PBRSB, I guess we don't need to worry about that since there would be at least one kernel CALL before context switch. -- Josh
