From: Konrad Rzeszutek Wilk <konrad.wilk@oracle.com>
To: Alexandre Chartre <alexandre.chartre@oracle.com>,
dave.hansen@intel.com, x86@kernel.org
Cc: Dave Hansen <dave.hansen@intel.com>,
Chao Gao <chao.gao@intel.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,
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, pbonzini@redhat.com
Subject: Re: [PATCH] KVM: x86: Set BHI_NO in guest when host is not affected by BHI
Date: Thu, 25 Apr 2024 16:45:10 -0400 [thread overview]
Message-ID: <ZirA1v5VL7Tdk0ej@char.us.oracle.com> (raw)
In-Reply-To: <2154b190-9cd1-4b24-83bb-460a708a45a3@oracle.com>
On Tue, Apr 16, 2024 at 10:41:58AM +0200, Alexandre Chartre wrote:
>
> On 4/15/24 19:17, Dave Hansen wrote:
> > > + /*
> > > + * The following Intel CPUs are affected by BHI, but they don't have
> > > + * the eIBRS feature. In that case, the default Spectre v2 mitigations
> > > + * are enough to also mitigate BHI. We mark these CPUs with NO_BHI so
> > > + * that X86_BUG_BHI doesn't get set and no extra BHI mitigation is
> > > + * enabled.
> > > + *
> > > + * This avoids guest VMs from enabling extra BHI mitigation when this
> > > + * is not needed. For guest, X86_BUG_BHI is never set for CPUs which
> > > + * don't have the eIBRS feature. But this doesn't happen in guest VMs
> > > + * as the virtualization can hide the eIBRS feature.
> > > + */
> > > + VULNWL_INTEL(IVYBRIDGE_X, NO_BHI),
> > > + VULNWL_INTEL(HASWELL_X, NO_BHI),
> > > + VULNWL_INTEL(BROADWELL_X, NO_BHI),
> > > + VULNWL_INTEL(SKYLAKE_X, NO_BHI),
> > > + VULNWL_INTEL(SKYLAKE_X, NO_BHI),
> >
> > Isn't this at odds with the existing comment?
> >
> > /* When virtualized, eIBRS could be hidden, assume vulnerable */
> >
> > Because it seems now that we've got two relatively conflicting pieces of
> > vulnerability information when running under a hypervisor.
>
> It's not at odd, it's an additional information. The comment covers the general
> case.
>
> When running under a hypervisor then the kernel can't rely on CPU features to
> find if the server has eIBRS or not, because the virtualization can be hiding
> eIBRS. And that's the problem because the kernel might enable BHI mitigation
> while it's not needed.
>
> For example on Skylake: on the host, the kernel won't see eIBRS so it won't set
> X86_BUG_BHI. But in a guest on the same platform, the kernel will set X86_BUG_BHI
> because it doesn't know if the server doesn't effectively have eIBRS or if eIBRS
> is hidden by virtualization.
>
> With the patch, the kernel can know if the CPU it is running on (e.g. Skylake)
> needs extra BHI mitigation or not. Then it can safely not enable BHI mitigation
> no matter if it is running on host or in guest.
Where do we want to go with this one?
The problem (which I think is not understood) is that on Skylake there
is no Enhanced IBRS support. There is either IBRS or retpoline - and when IBRS
is enabled it does the job of mitigating against BHI.
And as of right now on Skylake guests we enable BHI _and_ IBRS for extra
slowdown.
We can't disable IBRS as it mitigates against other bugs too, so how do
you folks want to disable automatically BHI on Skylake with the least
amount of code?
next prev parent reply other threads:[~2024-04-25 20:46 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 [this message]
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
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=ZirA1v5VL7Tdk0ej@char.us.oracle.com \
--to=konrad.wilk@oracle.com \
--cc=alexandre.chartre@oracle.com \
--cc=andrew.cooper3@citrix.com \
--cc=bp@alien8.de \
--cc=chao.gao@intel.com \
--cc=daniel.sneddon@linux.intel.com \
--cc=dave.hansen@intel.com \
--cc=dave.hansen@linux.intel.com \
--cc=gregkh@linuxfoundation.org \
--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).