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]

Message-ID: <caa51938-c587-4403-a9cd-16e8b585bc13@oracle.com>
Date: Thu, 11 Apr 2024 11:33:04 +0200
From: Alexandre Chartre <alexandre.chartre@...cle.com>
To: Andrew Cooper <andrew.cooper3@...rix.com>, x86@...nel.org,
        kvm@...r.kernel.org
Cc: alexandre.chartre@...cle.com, 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 4/11/24 10:43, Andrew Cooper wrote:
> 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".
> 

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?

Thanks,

alex.