Re: [PATCH] x86/bugs: Add force_cpu_bug= cmdline param

[Borislav Petkov]

On Tue, Nov 19, 2024 at 06:43:57PM +0000, Brendan Jackman wrote:
> Sometimes it can be very useful to run CPU vulnerability mitigations on
> systems where they aren't known to mitigate any real-world
> vulnerabilities. This can be handy for mundane reasons like "I wanna
> debug this on the machine that quickly", but also for research reasons:
> while some mitigations are focussed on individual vulns and uarches,

Unknown word [focussed] in commit message.
Suggestions: ['focused', 'focuses', 'cussed', 'fussed', 'foxed', "focus's", 'flossed', 'coursed', 'focus', 'fused', 'cursed', 'fessed', 'refocused', "ficus's"]

Spellchecker pls.

> others are fairly general, and it's strategically useful to have an idea
> how they'd perform on systems where we don't currently need them.

Please use passive voice in your commit message: no "we" or "I", etc,
and describe your changes in imperative mood.

Also, pls read section "2) Describe your changes" in
Documentation/process/submitting-patches.rst for more details.

Also, see section "Changelog" in
Documentation/process/maintainer-tip.rst

Bottom line is: personal pronouns are ambiguous in text, especially with
so many parties/companies/etc developing the kernel so let's avoid them
please.

Also check your comments in the code pls.

> As evidence for this being useful, a flag specifically for Retbleed was
> added in commit 5c9a92dec323 ("x86/bugs: Add retbleed=force").
> 
> It's a bit unfortunate that we have to do this by bug instead of by
> mitigation. However, we don't have clear identifiers for the mitigations
> that we do, so I don't think it's practical to do better here than "you
> can pretend you're on a vulnerable CPU - now go and read the docs for
> the per-vuln cmdline params to figure out how to run the mitigation you
> want".
> 
> Being an early_param() means we get to do this before identify_cpu() and
> cpu_select_mitigations(). But it's possible there's still other types of
> bugs that get setup earlier and might miss this override...
> 
> I've only tested this by booting a QEMU guest and checking /proc/cpuinfo.

Right, I don't mind this - question is, how do we make it such that people do
not use it in production and then come complaining to us why their CPU is
affected.

Yeah, sure, they better know what they're doing but I've seen pretty evil
perversions so far and us giving them enough rope just to shoot themselves is
fine.

What I don't think is fine is for *us* to shoot ourselves in the foot
by giving the users such a thing.

Btw, there's a clearcpuid= cmdline option which has the same potential and
that thing taints the kernel. Yours should probably do the same.

And it probably should be called "setcpuid=" as a counterpart to what we have
now...

Dunno, this is just my 2¢ opinion, don't have a clear idea yet what we wanna
do here...

-- 
Regards/Gruss,
    Boris.

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