summaryrefslogtreecommitdiff
path: root/scripts/Makefile.thinlto
diff options
context:
space:
mode:
authorBreno Leitao <leitao@debian.org>2026-10-29 07:45:03 -0700
committerBorislav Petkov (AMD) <bp@alien8.de>2026-11-01 17:32:45 -0800
commit3457b3bcd344005af894876cab4e634cabdcbb62 (patch)
tree2e8c78a236c3cacb59920cd851dd3a86a6b98733 /scripts/Makefile.thinlto
parent6628e7d4c6b25c8d18f1345e3a20d21829aae7e4 (diff)
downloadlinux-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