On Mon, Feb 20, 2023 at 11:04:56AM -0800, KP Singh wrote: > On Mon, Feb 20, 2023 at 11:00 AM Josh Poimboeuf <jpoimboe@xxxxxxxxxx> wrote: > > > > On Mon, Feb 20, 2023 at 10:33:56AM -0800, KP Singh wrote: > > > static char *stibp_state(void) > > > { > > > - if (spectre_v2_in_ibrs_mode(spectre_v2_enabled)) > > > + if (!spectre_v2_user_needs_stibp(spectre_v2_enabled)) > > > return ""; > > > > > > switch (spectre_v2_user_stibp) { > > > > > > Also Josh, is it okay for us to have a discussion and have me write > > > the patch as a v2? Your current patch does not even credit me at all. > > > Seems a bit unfair, but I don't really care. I was going to rev up the > > > patch with your suggestions. > > > > Well, frankly the patch needed a complete rewrite. The patch > > description was unclear about what the problem is and what's being > > Josh, this is a complex issue, we are figuring it out together on the > list. It's complex, that's why folks got it wrong in the first place. > Calling the patch obtuse and unclear is unfair! > > > fixed. The code was obtuse and the comments didn't help. I could tell > > by the other replies that I wasn't the only one confused. > > The patch you sent is not clear either, it implicitly ties in STIBP > with eIBRS. There is no explanation anywhere that IBRS just means > KERNEL_IBRS. Ok, so something like this on top? diff --git a/arch/x86/kernel/cpu/bugs.c b/arch/x86/kernel/cpu/bugs.c index b97c0d28e573..fb3079445700 100644 --- a/arch/x86/kernel/cpu/bugs.c +++ b/arch/x86/kernel/cpu/bugs.c @@ -1201,6 +1201,10 @@ spectre_v2_user_select_mitigation(void) /* * If no STIBP, enhanced IBRS is enabled, or SMT impossible, * STIBP is not required. + * + * For legacy IBRS, STIBP may still be needed because IBRS is only + * enabled in kernel space, so user space isn't protected from indirect + * branch prediction attacks from a sibling CPU thread. */ if (!boot_cpu_has(X86_FEATURE_STIBP) || !smt_possible ||