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,
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.

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.

Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
 Documentation/admin-guide/kernel-parameters.txt |  6 ++++
 arch/x86/kernel/cpu/common.c                    | 40 +++++++++++++++++++++++++
 2 files changed, 46 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index d401577b5a6ace87d250d9b1cc200691c6a0ed4e..260267a6d555076735fda09d171c918e6412b6e1 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1559,6 +1559,12 @@
 	floppy=		[HW]
 			See Documentation/admin-guide/blockdev/floppy.rst.
 
+	force_cpu_bug=	[X86,EARLY]
+			Force the kernel to assume the CPU is affected by the
+			given bug, regardless of its built-in information about
+			individual models.  Comma-separated list of the names of
+			vulnerabilities that would appear in /proc/cpuinfo.
+
 	forcepae	[X86-32]
 			Forcefully enable Physical Address Extension (PAE).
 			Many Pentium M systems disable PAE but may have a
diff --git a/arch/x86/kernel/cpu/common.c b/arch/x86/kernel/cpu/common.c
index f43bb974fc66d7b21ad52c64da22694ccc274187..b86b0200a5bf0de692f07d4ffef50ba7c360975d 100644
--- a/arch/x86/kernel/cpu/common.c
+++ b/arch/x86/kernel/cpu/common.c
@@ -1318,6 +1318,10 @@ static bool __init vulnerable_to_rfds(u64 x86_arch_cap_msr)
 	return cpu_matches(cpu_vuln_blacklist, RFDS);
 }
 
+/*
+ * This sets up what we _really_ think the CPU has. The user might override this
+ * later via force_cpu_bug.
+ */
 static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 {
 	u64 x86_arch_cap_msr = x86_read_arch_cap_msr();
@@ -1462,6 +1466,42 @@ static void __init cpu_set_bug_bits(struct cpuinfo_x86 *c)
 	setup_force_cpu_bug(X86_BUG_L1TF);
 }
 
+static int __init force_cpu_bug_parse_cmdline(char *str)
+{
+	if (!str)
+		return -EINVAL;
+
+	while (str) {
+		char *next = strchr(str, ',');
+		int i;
+
+		if (next) {
+			*next = 0;
+			next++;
+		}
+
+		/*
+		 * Linear search because there aren't many bugs (well, at least
+		 * not for the definition of "many" that is relevant here...).
+		 *
+		 * Some configs have no gaps so we could stop at the first NULL,
+		 * but it isn't worth the ifdeffery.
+		 */
+		for (i = 0; i < ARRAY_SIZE(x86_bug_flags); i++) {
+			if (x86_bug_flags[i] && !strcmp(str, x86_bug_flags[i])) {
+				setup_force_cpu_bug(X86_BUG(i));
+				goto found;
+			}
+		}
+		pr_err("Ignoring unknown force_cpu_bug= option (%s).", str);
+found:
+		str = next;
+	}
+
+	return 0;
+}
+early_param("force_cpu_bug", force_cpu_bug_parse_cmdline);
+
 /*
  * The NOPL instruction is supposed to exist on all CPUs of family >= 6;
  * unfortunately, that's not true in practice because of early VIA

---
base-commit: adc218676eef25575469234709c2d87185ca223a
change-id: 20241119-force-cpu-bug-94a08ab0239f

Best regards,
-- 
Brendan Jackman <jackmanb@google.com>

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

On Mon, 16 Dec 2024 at 18:17, Borislav Petkov <bp@alien8.de> 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.

On Mon, Dec 16, 2024 at 06:58:24PM +0100, Brendan Jackman wrote:
> OK yeah, tainting definitely makes sense, I think that goes quite a
> long way to avoid bogus bug reports?

It was my feeble attempt back then to leave enough breadcrumbs so that when
I see a bug report, I can say: "well, then don't do that then" and mark it as
invalid. :)

> I will also update the docs to sound scarier.

Right.

> 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.

Yeah, with your patch we're half-way there. Might as well do the whole thing
but again, this is only my opinion. Probably should hear what others have to
say first...

-- 
Regards/Gruss,
    Boris.

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

On Tue, Dec 17, 2024 at 12:17:52PM +0100, Borislav Petkov wrote:
> On Mon, Dec 16, 2024 at 06:58:24PM +0100, Brendan Jackman wrote:
> > OK yeah, tainting definitely makes sense, I think that goes quite a
> > long way to avoid bogus bug reports?
> 
> It was my feeble attempt back then to leave enough breadcrumbs so that when
> I see a bug report, I can say: "well, then don't do that then" and mark it as
> invalid. :)
> 
> > I will also update the docs to sound scarier.
> 
> Right.

Perhaps issue a pr_warn() for every bit set? People tend to not like
WARN/ERR in their production logs much :-)

> > 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.
> 
> Yeah, with your patch we're half-way there. Might as well do the whole thing
> but again, this is only my opinion. Probably should hear what others have to
> say first...

Given I'm the one that did the retbleed=force thing (and other force
options), I'm in favour.

Hi all, any thoughts on this?