diff options
| author | Breno Leitao <leitao@debian.org> | 2026-10-29 07:45:03 -0700 |
|---|---|---|
| committer | Borislav Petkov (AMD) <bp@alien8.de> | 2026-11-01 17:32:45 -0800 |
| commit | 3457b3bcd344005af894876cab4e634cabdcbb62 (patch) | |
| tree | 2e8c78a236c3cacb59920cd851dd3a86a6b98733 /scripts/Makefile.thinlto | |
| parent | 6628e7d4c6b25c8d18f1345e3a20d21829aae7e4 (diff) | |
| download | linux-next-3457b3bcd344005af894876cab4e634cabdcbb62.tar.gz linux-next-3457b3bcd344005af894876cab4e634cabdcbb62.zip | |
x86/bugs: Select the BHI mitigation based on the attack vector properly
The BHI mitigation selection is inconsistent with the documentation
(attack_vector_controls.rst), which lists BHI under both the
user->kernel and guest->host attack vectors. bhi_select_mitigation()
only enables it when CPU_MITIGATE_GUEST_HOST is set; otherwise it
selects BHI_MITIGATION_OFF, even if CPU_MITIGATE_USER_KERNEL is set.
As a result, a kernel compiled with KVM disabled gets BHI automatically
disabled, since CPU_MITIGATE_GUEST_HOST defaults to off without KVM.
This is a bug, given that CPU_MITIGATE_USER_KERNEL still needs it: on
affected Intel CPUs these kernels lose BHI_DIS_S or the BHB clearing
loop by default. Booting with mitigations=auto,no_guest_host has the
same effect.
Select BHI_MITIGATION_ON whenever user->kernel is mitigated, and keep
BHI_MITIGATION_VMEXIT_ONLY for the guest->host-only case.
[ bp: Clarify commit title. ]
Fixes: ddcd4d3cb37c ("x86/bugs: Add attack vector controls for BHI")
Signed-off-by: Breno Leitao <leitao@debian.org>
Signed-off-by: Borislav Petkov (AMD) <bp@alien8.de>
Acked-by: David Kaplan <david.kaplan@amd.com>
Cc: <stable@kernel.org>
Link: https://patch.msgid.link/20261029-bhi-attack-vector-v1-1-29cfa697efb6@debian.org
Diffstat (limited to 'scripts/Makefile.thinlto')
0 files changed, 0 insertions, 0 deletions
