On Mon, 16 Dec 2024 at 18:17, Borislav Petkov <bp@xxxxxxxxx> wrote:
>
> 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.
Ack.
> > 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.
OK yeah, tainting definitely makes sense, I think that goes quite a
long way to avoid bogus bug reports? I will also update the docs to
sound scarier.
> And it probably should be called "setcpuid=" as a counterpart to what we have
> now...
So do you think we should allow setting arbitrary cpu features? That
seems like a much bigger footgun. But then again, the difference
between "big footgun" and "very big footgun" is not that important,
either way it needs to be clear to users that this is a scary red
button.
