Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI

[Alexandre Chartre <alexandre.chartre@oracle.com>]

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.