From: Alexandre Chartre <alexandre.chartre@oracle.com>
To: Paolo Bonzini <pbonzini@redhat.com>
Cc: alexandre.chartre@oracle.com,
Andrew Cooper <andrew.cooper3@citrix.com>,
x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org, daniel.sneddon@linux.intel.com,
pawan.kumar.gupta@linux.intel.com, tglx@linutronix.de,
konrad.wilk@oracle.com, peterz@infradead.org,
gregkh@linuxfoundation.org, seanjc@google.com,
dave.hansen@linux.intel.com, nik.borisov@suse.com,
kpsingh@kernel.org, longman@redhat.com, bp@alien8.de
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI
Date: Thu, 11 Apr 2024 17:12:56 +0200 [thread overview]
Message-ID: <99ad2011-58b7-42c8-9ee5-af598c76a732@oracle.com> (raw)
In-Reply-To: <CABgObfZU_uLAPzDV--n67H3Hq6OKxUO=FQa2MH3CjdgTQR8pJg@mail.gmail.com>
On 4/11/24 16:46, Paolo Bonzini wrote:
> On Thu, Apr 11, 2024 at 4:34 PM Alexandre Chartre
> <alexandre.chartre@oracle.com> wrote:
>> 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);
>
> No, that you cannot do because the hypervisor can and will fake the
> family/model/stepping.
>
> However, looking again at the original patch you submitted, I think
> the review was confusing host and guest sides. If the host is "not
> affected", i.e. the host *genuinely* does not have eIBRS, it can set
> BHI_NO and that will bypass the "always mitigate in a guest" bit.
>
> I think that's robust and boot_cpu_has_bug(X86_BUG_BHI) is the right
> way to do it.
>
> If a VM migration pool has both !eIBRS and eIBRS machines, it will
> combine the two; on one hand it will not set the eIBRS bit (bit 1), on
> the other hand it will not set BHI_NO either, and it will set the
> hypervisor bit. The result is that the guest *will* use mitigations.
>
> To double check, from the point of view of a nested hypervisor, you
> could set BHI_NO in a nested guest:
> * if the nested hypervisor has BHI_NO passed from the outer level
> * or if its CPUID passes cpu_matches(cpu_vuln_whitelist, NO_BHI)
> * but it won't matter whether the nested hypervisor lacks eIBRS,
> because that bit is not reliable in a VM
>
> The logic you'd use in KVM therefore is:
>
> (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)))
>
> but that is exactly !boot_cpu_has_bug(X86_BUG_BHI) and is therefore
> what Alexandre's patch does.
>
> So I'll wait for further comments but I think the patch is correct.
>
I think that Andrew's concern is that if there is no eIBRS on the host then
we do not set X86_BUG_BHI on the host because we know the kernel which is
running and this kernel has some mitigations (other than the explicit BHI
mitigations) and these mitigations are enough to prevent BHI. But still
the cpu is affected by BHI.
If you set ARCH_CAP_BHI_NO for the guest then you tell the guest that the
cpu is not affected by BHI although it is. The guest can be running a
different kernel or OS which doesn't necessarily have the (basic) mitigations
used in the host kernel that mitigate BHI.
alex.
next prev parent reply other threads:[~2024-04-11 15:13 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-04-11 7:24 [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI Alexandre Chartre
2024-04-11 7:34 ` Nikolay Borisov
2024-04-11 7:49 ` Alexandre Chartre
2024-04-11 7:51 ` Greg KH
2024-04-11 8:00 ` Alexandre Chartre
2024-04-11 7:51 ` Nikolay Borisov
2024-04-11 8:43 ` Andrew Cooper
2024-04-11 9:33 ` Alexandre Chartre
2024-04-11 9:38 ` Andrew Cooper
2024-04-11 11:14 ` Chao Gao
2024-04-11 13:20 ` Alexandre Chartre
2024-04-15 15:14 ` Alexandre Chartre
2024-04-15 17:17 ` Dave Hansen
2024-04-16 8:41 ` Alexandre Chartre
2024-04-25 20:45 ` Konrad Rzeszutek Wilk
2024-04-11 13:22 ` Paolo Bonzini
2024-04-11 13:32 ` Alexandre Chartre
2024-04-11 14:13 ` Andrew Cooper
2024-04-11 14:33 ` Alexandre Chartre
2024-04-11 14:46 ` Paolo Bonzini
2024-04-11 15:12 ` Alexandre Chartre [this message]
2024-04-11 15:20 ` Paolo Bonzini
2024-04-11 15:56 ` Chao Gao
2024-04-11 20:50 ` Konrad Rzeszutek Wilk
2024-04-12 3:24 ` Chao Gao
2024-04-12 16:33 ` Konrad Rzeszutek Wilk
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=99ad2011-58b7-42c8-9ee5-af598c76a732@oracle.com \
--to=alexandre.chartre@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--cc=konrad.wilk@oracle.com \
--cc=kpsingh@kernel.org \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=nik.borisov@suse.com \
--cc=pawan.kumar.gupta@linux.intel.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=seanjc@google.com \
--cc=tglx@linutronix.de \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).