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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date: Thu, 11 Apr 2024 09:43:05 +0100
From: Andrew Cooper <andrew.cooper3@...rix.com>
To: Alexandre Chartre <alexandre.chartre@...cle.com>, x86@...nel.org,
 kvm@...r.kernel.org
Cc: linux-kernel@...r.kernel.org, daniel.sneddon@...ux.intel.com,
 pawan.kumar.gupta@...ux.intel.com, tglx@...utronix.de,
 konrad.wilk@...cle.com, peterz@...radead.org, gregkh@...uxfoundation.org,
 seanjc@...gle.com, dave.hansen@...ux.intel.com, nik.borisov@...e.com,
 kpsingh@...nel.org, longman@...hat.com, bp@...en8.de, pbonzini@...hat.com
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected
 by BHI

On 11/04/2024 8:24 am, Alexandre Chartre wrote:
> When a system is not affected by the BHI bug then KVM should
> configure guests with BHI_NO to ensure they won't enable any
> BHI mitigation.
>
> Signed-off-by: Alexandre Chartre <alexandre.chartre@...cle.com>
> ---
>  arch/x86/kvm/x86.c | 3 +++
>  1 file changed, 3 insertions(+)
>
> diff --git a/arch/x86/kvm/x86.c b/arch/x86/kvm/x86.c
> index 984ea2089efc..f43d3c15a6b7 100644
> --- a/arch/x86/kvm/x86.c
> +++ b/arch/x86/kvm/x86.c
> @@ -1678,6 +1678,9 @@ static u64 kvm_get_arch_capabilities(void)
>  	if (!boot_cpu_has_bug(X86_BUG_GDS) || gds_ucode_mitigated())
>  		data |= ARCH_CAP_GDS_NO;
>  
> +	if (!boot_cpu_has_bug(X86_BUG_BHI))
> +		data |= ARCH_CAP_BHI_NO;

This isn't true or safe.

Linux only sets X86_BUG_BHI on a subset of affected parts.

Skylake for example *is* affected by BHI.  It's just that existing
mitigations are believed to suffice to mitigate BHI too.

"you happen to be safe if you're doing something else too" doesn't
remotely have the same meaning as "hardware doesn't have a history based
predictor".

~Andrew