arch/x86/include/asm/cpufeature.h | 1 + arch/x86/kernel/cpu/common.c | 139 +++++++++++++++++++++++--------------- 2 files changed, 87 insertions(+), 53 deletions(-)
For testing, development, and experimentation, add the ability to force
the kernel to behave as if the CPU has a bug, even if it doesn't, using
a command-line param.
Also do this in general for CPU flags, since:
- The infrastructure is the same so there is almost no extra
implementation complexity.
- While setting random CPU flags is certain to break the kernel in
mysterious and horrifying ways, this is not dramatically worse than
setting CPU bugs. Although CPU bug mitigations don't have any very
obvious ways to break the system if run on the wrong hardware, it's
still very much an unsupported configuration, even beyond the
security concern implied breaking mitigation logic.
Since a taint and scary docs are necessary regardless, supporting
arbitrary CPU flags doesn't add significant maintenance/support
burden either.
Signed-off-by: Brendan Jackman <jackmanb@google.com>
---
Changes in v2:
- Switched from a bugs-only force_cpu_bug= to a more general setcpuid=.
- Made it taint the kernel.
- Made docs sound scarier.
- Spellchecked and avoided new usage of personal pronouns.
- Link to v1: https://lore.kernel.org/r/20241119-force-cpu-bug-v1-1-2aa31c6c1ccf@google.com
---
Brendan Jackman (3):
x86/cpu: Create helper to parse clearcpuid param
x86/cpu: Add setcpuid cmdline param
x86/cpu: Enable modifying bug flags with {clear,set}puid
arch/x86/include/asm/cpufeature.h | 1 +
arch/x86/kernel/cpu/common.c | 139 +++++++++++++++++++++++---------------
2 files changed, 87 insertions(+), 53 deletions(-)
---
base-commit: eabcdba3ad4098460a376538df2ae36500223c1e
change-id: 20241119-force-cpu-bug-94a08ab0239f
Best regards,
--
Brendan Jackman <jackmanb@google.com>
Hi folks, happy new year. I hope this ping isn't too aggressive given the season - please let me know if it is. Any new thoughts on this?
* Brendan Jackman <jackmanb@google.com> wrote:
> Hi folks, happy new year. I hope this ping isn't too aggressive given
> the season - please let me know if it is.
>
> Any new thoughts on this?
Sorry, this series got lost in the holiday season (apparently you
weren't nearly pushy enough to breach the maintainer patch-detection
noise/signal level :-), and this functionality is definitely useful and
the series looks good to me.
Integration with clearcpuid= is so much more generic than the original
variant and reuses a lot of that logic, so that's a big plus.
I've applied it to the x86 tree under the tip:x86/cpu branch and if
everything goes fine in testing it should hit v6.15 in a couple of
weeks.
One additional thing - which I'd suggest we make a 4th patch, because
it affects the existing clearcpuid= behavior - is to extend
set/clearcpuid= with a bit more boot time verbosity, right now it
taints the kernel:
/* empty-string, i.e., ""-defined feature flags */
if (!x86_cap_flags[bit])
pr_cont(" " X86_CAP_FMT_NUM, x86_cap_flag_num(bit));
else
pr_cont(" " X86_CAP_FMT, x86_cap_flag(bit));
if (set)
setup_force_cpu_cap(bit);
else
setup_clear_cpu_cap(bit);
taint++;
I'd suggest we do what PeterZ suggested back in December: in addition
to the tainting, also emit an informative pr_warn() for every CPU
feature bit enabled/disabled over what was present, and maybe make a
bit of a distinction between 'feature' and 'bug' feature bits.
Thanks,
Ingo
* Ingo Molnar <mingo@kernel.org> wrote:
>
> * Brendan Jackman <jackmanb@google.com> wrote:
>
> > Hi folks, happy new year. I hope this ping isn't too aggressive given
> > the season - please let me know if it is.
> >
> > Any new thoughts on this?
>
> Sorry, this series got lost in the holiday season (apparently you
> weren't nearly pushy enough to breach the maintainer patch-detection
> noise/signal level :-), and this functionality is definitely useful and
> the series looks good to me.
>
> Integration with clearcpuid= is so much more generic than the original
> variant and reuses a lot of that logic, so that's a big plus.
>
> I've applied it to the x86 tree under the tip:x86/cpu branch and if
> everything goes fine in testing it should hit v6.15 in a couple of
> weeks.
>
> One additional thing - which I'd suggest we make a 4th patch, because
> it affects the existing clearcpuid= behavior - is to extend
> set/clearcpuid= with a bit more boot time verbosity, right now it
> taints the kernel:
>
> /* empty-string, i.e., ""-defined feature flags */
> if (!x86_cap_flags[bit])
> pr_cont(" " X86_CAP_FMT_NUM, x86_cap_flag_num(bit));
> else
> pr_cont(" " X86_CAP_FMT, x86_cap_flag(bit));
>
> if (set)
> setup_force_cpu_cap(bit);
> else
> setup_clear_cpu_cap(bit);
> taint++;
>
>
> I'd suggest we do what PeterZ suggested back in December: in addition
> to the tainting, also emit an informative pr_warn() for every CPU
> feature bit enabled/disabled over what was present, and maybe make a
> bit of a distinction between 'feature' and 'bug' feature bits.
Ie. what I mean is that at minimum upgrade the output from pr_info() to
pr_warn() - but maybe also make it clear in the output that the kernel
is tainted and things may break as a result of modifying the feature
bits.
Thanks,
Ingo
On Fri, Feb 28, 2025 at 05:29:45PM +0100, Ingo Molnar wrote:
> * Ingo Molnar <mingo@kernel.org> wrote:
> > Integration with clearcpuid= is so much more generic than the original
> > variant and reuses a lot of that logic, so that's a big plus.
> >
> > I've applied it to the x86 tree under the tip:x86/cpu branch and if
> > everything goes fine in testing it should hit v6.15 in a couple of
> > weeks.
It seems you applied this version (v2) while there was actually a
review from Boris on this and it led to v3:
https://lore.kernel.org/linux-kernel/20250218-force-cpu-bug-v3-0-da3df43d1936@google.com/
This is weird, I can't see Boris' comments on Lore, even though they
are Cc'd to linux-kernel@vger.kernel.org. I think there was some
downtime on Lore recently, maybe they got lost?
> > One additional thing - which I'd suggest we make a 4th patch, because
> > it affects the existing clearcpuid= behavior - is to extend
> > set/clearcpuid= with a bit more boot time verbosity, right now it
> > taints the kernel:
> >
> > /* empty-string, i.e., ""-defined feature flags */
> > if (!x86_cap_flags[bit])
> > pr_cont(" " X86_CAP_FMT_NUM, x86_cap_flag_num(bit));
> > else
> > pr_cont(" " X86_CAP_FMT, x86_cap_flag(bit));
> >
> > if (set)
> > setup_force_cpu_cap(bit);
> > else
> > setup_clear_cpu_cap(bit);
> > taint++;
> >
> >
> > I'd suggest we do what PeterZ suggested back in December: in addition
> > to the tainting, also emit an informative pr_warn() for every CPU
> > feature bit enabled/disabled over what was present, and maybe make a
> > bit of a distinction between 'feature' and 'bug' feature bits.
>
> Ie. what I mean is that at minimum upgrade the output from pr_info() to
> pr_warn() - but maybe also make it clear in the output that the kernel
> is tainted and things may break as a result of modifying the feature
> bits.
Anyway, yep, I will send some upgrades to the logging, plus any diff
that got lost from v2 to v3 as a new series.
Thanks for taking a look!
© 2016 - 2025 Red Hat, Inc.