lkml.org 
[lkml]   [2024]   [Apr]   [11]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    SubjectRe: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI
    From


    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.

    \
     
     \ /
      Last update: 2024-05-27 16:35    [W:3.967 / U:0.064 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site