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: <d248fdfb-e89d-409f-97f6-5ded84a5b495@oracle.com>
Date: Thu, 11 Apr 2024 09:49:55 +0200
From: Alexandre Chartre <alexandre.chartre@...cle.com>
To: Nikolay Borisov <nik.borisov@...e.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,
        andrew.cooper3@...rix.com, dave.hansen@...ux.intel.com,
        kpsingh@...nel.org, longman@...hat.com, bp@...en8.de,
        pbonzini@...hat.com, alexandre.chartre@...cle.com
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected
 by BHI


On 4/11/24 09:34, Nikolay Borisov wrote:
> 
> 
> On 11.04.24 г. 10:24 ч., 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;
>> +
> 
> But this is already handled since ARCH_CAP_BHI_NO is added to
> KVM_SUPPORTED_ARCH_CAP so when the host caps are read that bit is
> going to be set there, if it's set for the physical cpu of course.

Correct, if the host has ARCH_CAP_BHI_NO then it will be propagated to the
guest. But the host might not have ARCH_CAP_BHI_NO set and not be affected
by BHI.

That's the case for example of Skylake servers: they don't have ARCH_CAP_BHI_NO,
but they are not affected by BHI because they don't have eIBRS. However, a guest
will think it is affected because it doesn't know if eIBRS is present on the
system (because virtualization can hide it).

I tested on Skylake:

Without the patch, both host and guest are running 6.9.0-rc3, then BHI mitigations are:

- Host:  BHI: Not affected
- Guest: BHI: SW loop, KVM: SW loop

=> so guest enables BHI SW loop mitigation although host doesn't need mitigation.

With the patch on the host, guest still running 6.9.0-rc3, then BHI mitigations are:

- Host:  BHI: Not affected
- Guest: BHI: Not affected

=> now guest doesn't enable BHI mitigation, like the host.

Thanks,

alex.