Re: [PATCH v2 11/35] x86/bugs: Restructure spectre_v1 mitigation

[Borislav Petkov]

On Thu, Nov 14, 2024 at 03:33:39PM -0800, Josh Poimboeuf wrote:
> On Thu, Nov 14, 2024 at 04:45:37PM +0000, Kaplan, David wrote:
> > 1) the CPU is not vulnerable (it doesn't have the bug)
> > 2) the CPU is vulnerable but mitigations=off was passed
> > 3) the CPU is vulnerable but the bug-specific mitigation was disabled (e.g., retbleed=off)
> > 4) the CPU is vulnerable, mitigations were not disabled, but no mitigation is available (perhaps it wasn't compiled in)
> > 
> > We absolutely should not print a message in case #1, because the CPU isn't vulnerable.  And we should probably always print a message in case 4 to warn the user.  Question is really about cases 2 and 3.
> > 
> > Today, some bugs print a message saying the CPU is vulnerable in case 2 and 3 (e.g., gds)
> > Some bugs don't print a message in case 2, but do in case 3 (e.g., spectre_v1)
> > Some don't print a message in case 2 or 3 (e.g., retbleed)
> > 
> > Case 4 is things like where you need SRSO mitigation but CONFIG_MITIGATION_SRSO was disabled.
> > 
> > So which do we want?  It would be nice to be consistent and I can do that while reworking these functions.
> > 
> > If we're going to argue that command line options mean the user knows
> > what they're doing, that's probably an argument for saying do not
> > print anything in cases 2 and 3 (since both relate to explicit command
> > line options).  I'm not sure if it really makes sense to differentiate
> > these cases.
> 
> IMO, mitigations=off shouldn't show any bug-specific messages, as user
> doesn't care about the specifics, they just want everything off.
> 
> That said, they still might want to see some kind of "all mitigations
> disabled" message to indicate the option actually worked.
> 
> For similar reasons I'd argue the bug-specific toggle should show a
> bug-specific vulnerable message.

I guess that makes sense, and the bikeshed is already painted. :)

I mean, there's always

$ grep -r . /sys/devices/system/cpu/vulnerabilities/

so it's not like we don't have that info anywhere...

-- 
Regards/Gruss,
    Boris.

https://people.kernel.org/tglx/notes-about-netiquette