linux.git/arch/x86/kernel/cpu/bugs.c, branch v6.18

x86/bugs: Remove dead code which might prevent from building

2025-10-24T16:42:00+00:00

Clang, in particular, is not happy about dead code:

arch/x86/kernel/cpu/bugs.c:1830:20: error: unused function 'match_option' [-Werror,-Wunused-function]
 1830 | static inline bool match_option(const char *arg, int arglen, const char *opt)
      |                    ^~~~~~~~~~~~
1 error generated.

Remove a leftover from the previous cleanup.

Fixes: 02ac6cc8c5a1 ("x86/bugs: Simplify SSB cmdline parsing")
Signed-off-by: Andy Shevchenko 
Signed-off-by: Dave Hansen 
Link: https://patch.msgid.link/20251024125959.1526277-1-andriy.shevchenko%40linux.intel.com

x86/bugs: Qualify RETBLEED_INTEL_MSG

2025-10-21T10:32:28+00:00

When retbleed mitigation is disabled, the kernel already prints an info
message that the system is vulnerable.  Recent code restructuring also
inadvertently led to RETBLEED_INTEL_MSG being printed as an error, which is
unnecessary as retbleed mitigation was already explicitly disabled (by config
option, cmdline, etc.).

Qualify this print statement so the warning is not printed unless an actual
retbleed mitigation was selected and is being disabled due to incompatibility
with spectre_v2.

Fixes: e3b78a7ad5ea ("x86/bugs: Restructure retbleed mitigation")
Closes: https://bugzilla.kernel.org/show_bug.cgi?id=220624
Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://patch.msgid.link/20251003171936.155391-1-david.kaplan@amd.com

x86/bugs: Report correct retbleed mitigation status

2025-09-16T11:32:18+00:00

On Intel CPUs, the default retbleed mitigation is IBRS/eIBRS but this
requires that a similar spectre_v2 mitigation is applied.  If the user
selects a different spectre_v2 mitigation (like spectre_v2=retpoline) a
warning is printed but sysfs will still report 'Mitigation: IBRS' or
'Mitigation: Enhanced IBRS'.  This is incorrect because retbleed is not
mitigated, and IBRS is not actually set.

Fix this by choosing RETBLEED_MITIGATION_NONE in this scenario so the
kernel correctly reports the system as vulnerable to retbleed.

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/20250915134706.3201818-1-david.kaplan@amd.com

x86/bugs: Fix reporting of LFENCE retpoline

2025-09-16T11:21:21+00:00

The LFENCE retpoline mitigation is not secure but the kernel prints
inconsistent messages about this fact.  The dmesg log says 'Mitigation:
LFENCE', implying the system is mitigated.  But sysfs reports 'Vulnerable:
LFENCE' implying the system (correctly) is not mitigated.

Fix this by printing a consistent 'Vulnerable: LFENCE' string everywhere
when this mitigation is selected.

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/20250915134706.3201818-1-david.kaplan@amd.com

x86/bugs: Fix spectre_v2 forcing

2025-09-16T10:59:55+00:00

There were two oddities with spectre_v2 command line options.

First, any option other than 'off' or 'auto' would force spectre_v2
mitigations even if the CPU (hypothetically) wasn't vulnerable to spectre_v2.
That was inconsistent with all the other bugs where mitigations are ignored
unless an explicit 'force' option is specified.

Second, even though spectre_v2 mitigations would be enabled in these cases,
the X86_BUG_SPECTRE_V2 bit wasn't set.  This is again inconsistent with the
forcing behavior of other bugs and arguably incorrect as it doesn't make sense
to enable a mitigation if the X86_BUG bit isn't set.

Fix both issues by only forcing spectre_v2 mitigations when the
'spectre_v2=on' option is specified (which was already called
SPECTRE_V2_CMD_FORCE) and setting the relevant X86_BUG_* bits in that case.

This also allows for simplifying bhi_update_mitigation() because
spectre_v2_cmd will now always be SPECTRE_V2_CMD_NONE if the CPU is immune to
spectre_v2.

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Link: https://lore.kernel.org/20250915134706.3201818-1-david.kaplan@amd.com

x86/bugs: Remove uses of cpu_mitigations_off()

2025-09-15T19:10:44+00:00

cpu_mitigations_off() is no longer needed because all bugs use attack
vector controls to select a mitigation, and cpu_mitigations_off() is
equivalent to no attack vectors being selected.

Remove the few remaining unnecessary uses of this function in this file.

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Pawan Gupta

x86/bugs: Simplify SSB cmdline parsing

2025-09-15T16:04:20+00:00

Simplify the SSB command line parsing by selecting a mitigation directly, as
is done in most of the simpler vulnerabilities.  Use early_param() instead of
cmdline_find_option() for consistency with the other mitigation selections.

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Pawan Gupta 
Link: https://lore.kernel.org/r/20250819192200.2003074-4-david.kaplan@amd.com

x86/bugs: Use early_param() for spectre_v2

2025-09-15T15:26:49+00:00

Most of the mitigations in bugs.c use early_param() for command line parsing.
Rework the spectre_v2 and nospectre_v2 command line options to be
consistent with the others.

Remove spec_v2_print_cond() as informing the user of the their cmdline
choice isn't interesting.

  [ bp: Zap spectre_v2_check_cmd(). ]

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Pawan Gupta 
Link: https://lore.kernel.org/r/20250819192200.2003074-3-david.kaplan@amd.com

x86/bugs: Use early_param() for spectre_v2_user

2025-09-15T15:07:22+00:00

Most of the mitigations in bugs.c use early_param() to parse their command
line options.  Modify spectre_v2_user to use early_param() for consistency.

Remove spec_v2_user_print_cond() because informing a user about their
cmdline choice isn't very interesting and the chosen mitigation is already
printed in spectre_v2_user_update_mitigation().

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD) 
Reviewed-by: Pawan Gupta 
Link: https://lore.kernel.org/r/20250819192200.2003074-2-david.kaplan@amd.com

x86/bugs: Add attack vector controls for VMSCAPE

2025-09-12T21:19:29+00:00

Use attack vector controls to select whether VMSCAPE requires mitigation,
similar to other bugs.

Signed-off-by: David Kaplan 
Signed-off-by: Borislav Petkov (AMD)