Messages in this thread | | | Date | Thu, 11 Apr 2024 16:33:19 +0200 | Subject | Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI | From | Alexandre Chartre <> |
| |
On 4/11/24 16:13, Andrew Cooper wrote: > On 11/04/2024 2:32 pm, Alexandre Chartre wrote: >> >> On 4/11/24 15:22, Paolo Bonzini wrote: >>> On Thu, Apr 11, 2024 at 11:34 AM Alexandre Chartre >>> <alexandre.chartre@oracle.com> wrote: >>>> >>>> So you mean we can't set ARCH_CAP_BHI_NO for the guest because we >>>> don't know >>>> if the guest will run the (other) existing mitigations which are >>>> believed to >>>> suffice to mitigate BHI? >>>> >>>> The problem is that we can end up with a guest running extra BHI >>>> mitigations >>>> while this is not needed. Could we inform the guest that eIBRS is >>>> not available >>>> on the system so a Linux guest doesn't run with extra BHI mitigations? >>> >>> The (Linux or otherwise) guest will make its own determinations as to >>> whether BHI mitigations are necessary. If the guest uses eIBRS, it >>> will run with mitigations. If you hide bit 1 of >>> MSR_IA32_ARCH_CAPABILITIES from the guest, it may decide to disable >>> it. But if the guest decides to use eIBRS, I think it should use >>> mitigations even if the host doesn't. >> >> The problem is not on servers which have eIBRS, but on servers which >> don't. >> >> If there is no eIBRS on the server, then the guest doesn't know if >> there is >> effectively no eIBRS on the server or if eIBRS is hidden by the >> virtualization >> so it applies the BHI mitigation even when that's not needed (i.e. >> when eIBRS >> is effectively not present the server). >> >>> It's a different story if the host isn't susceptible altogether. The >>> ARCH_CAP_BHI_NO bit *can* be set if the processor doesn't have the bug >>> at all, which would be true if cpu_matches(cpu_vuln_whitelist, >>> NO_BHI). I would apply a patch to do that. >>> >> >> Right. I have just suggested to enumerate cpus which have eIBRS with >> NO_BHI, >> but we need would that precise list of cpus. > > Intel stated that there are no current CPUs for which NO_BHI would be true. > > What I take this to mean is "no CPUs analysing backwards as far as Intel > cared to go". >
Still, we could enumerate CPUs which don't have eIBRS independently of NO_BHI (if we have a list of such CPUs) and set X86_BUG_BHI for cpus with eIBRS.
So in arch/x86/kernel/cpu/common.c, replace:
/* When virtualized, eIBRS could be hidden, assume vulnerable */ if (!(ia32_cap & ARCH_CAP_BHI_NO) && !cpu_matches(cpu_vuln_whitelist, NO_BHI) && (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED) || boot_cpu_has(X86_FEATURE_HYPERVISOR))) setup_force_cpu_bug(X86_BUG_BHI);
with something like:
if (!(ia32_cap & ARCH_CAP_BHI_NO) && !cpu_matches(cpu_vuln_whitelist, NO_BHI) && (boot_cpu_has(X86_FEATURE_IBRS_ENHANCED) || !cpu_matches(cpu_vuln_whitelist, NO_EIBRS))) setup_force_cpu_bug(X86_BUG_BHI);
alex.
| |