Should all kernel patches for CPU bugs be unconditionally enabled? Vs Performance vs Applicability

Development
21

This is an important point. I was wondering about this too. And I could be wrong here. It would be very much desirable to simplify this. However, I think mitigations=auto isn’t the same as mitigations=force, while the latter does not seem to exist yet. This seems like a missing kernel feature but I wasn’t sure it’s worth a feature request.

mitigations=auto means “conditionally enable” while mitigations=force would mean “unconditionally enable”.

Hardware vulnerabilities — The Linux Kernel documentation and following pages don’t mention mitigations=.

quote The kernel's command-line parameters — The Linux Kernel documentation

mitigations=
[X86,PPC,S390,ARM64] Control optional mitigations for
CPU vulnerabilities. This is a set of curated,
arch-independent options, each of which is an
aggregation of existing arch-specific options.

auto (default)

I.e. auto is already the default. mitigations=auto would essentially do nothing.

auto,nosmt
Mitigate all CPU vulnerabilities, disabling SMT
if needed. This is for users who always want to
be fully mitigated, even if it means losing SMT.
Equivalent to: l1tf=flush,nosmt [X86]
mds=full,nosmt [X86]
tsx_async_abort=full,nosmt [X86]

It does not set l1tf=full,force, nosmt=force, tsx=off, spectre_v2=on, pti=on.

Kernel — CLIP OS 5.0.0_beta3 documentation writes

  • mitigations : This parameter controls optional mitigations for CPU vulnerabilities in an arch-independent and more coarse-grained way. For now, we keep using arch-specific options for the sake of explicitness. Not setting this parameter equals setting it to auto , which itself does not update anything.
1 Like