Messages in this thread | | | Date | Tue, 22 Feb 2022 16:00:18 +0100 | From | Peter Zijlstra <> | Subject | Re: [PATCH 16/29] x86/bugs: Disable Retpoline when IBT |
| |
On Fri, Feb 18, 2022 at 06:15:30PM -0800, Josh Poimboeuf wrote:
> This code is confusing, not helped by the fact that the existing code > already looks like spaghetti.
I'd say that's an insult to spaghetti.
> Assuming IBT systems also have eIBRS (right?), I don't think the above > SPECTRE_V2_CMD_{FORCE,AUTO} cases would be possible.
Virt FTW.. if I don't handle it, some idiot will create a virtual machine that doesn't expose eIBRS but does do IBT just to spite me.
> AFAICT, if execution reached the retpoline_generic label, the user > specified either RETPOLINE or RETPOLINE_GENERIC.
Only RETPOLINE_GENERIC;
> I'm not sure it makes sense to put RETPOLINE in the "silent" list. If > the user boots an Intel system with spectre_v2=retpoline on the cmdline, > they're probably expecting a traditional retpoline and should be warned > if that changes, especially if it's a "demotion".
too friggin bad as to expectations; retpoline == auto. Not saying that makes sense, just saying that's what it does.
> In that case the switch statement isn't even needed. It can instead > just unconditinoally print the warning. > > > Also, why "demote" retpoline to LFENCE rather than attempting to > "promote" it to eIBRS? Maybe there's a good reason but it probably at > least deserves some mention in the commit log.
The current code will never select retpoline if eibrs is available.
The alternative is doing this in apply_retpolines(), but that might be even more nasty.
| |