From: Sean Christopherson <seanjc@google.com>
To: Borislav Petkov <bp@alien8.de>
Cc: Jon Kohler <jon@nutanix.com>,
Thomas Gleixner <tglx@linutronix.de>,
Ingo Molnar <mingo@redhat.com>,
Dave Hansen <dave.hansen@linux.intel.com>,
"x86@kernel.org" <x86@kernel.org>,
"H. Peter Anvin" <hpa@zytor.com>,
Paolo Bonzini <pbonzini@redhat.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Wanpeng Li <wanpengli@tencent.com>,
Jim Mattson <jmattson@google.com>, Joerg Roedel <joro@8bytes.org>,
Josh Poimboeuf <jpoimboe@redhat.com>,
Peter Zijlstra <peterz@infradead.org>,
Balbir Singh <sblbir@amazon.com>,
Kim Phillips <kim.phillips@amd.com>,
"linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>,
"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
Andrea Arcangeli <aarcange@redhat.com>,
Kees Cook <keescook@chromium.org>,
Waiman Long <longman@redhat.com>
Subject: Re: [PATCH v3] x86/speculation, KVM: only IBPB for switch_mm_always_ibpb on vCPU load
Date: Fri, 29 Apr 2022 20:29:30 +0000 [thread overview]
Message-ID: <YmxKqpWFvdUv+GwJ@google.com> (raw)
In-Reply-To: <Ymw9UZDpXym2vXJs@zn.tnic>
On Fri, Apr 29, 2022, Borislav Petkov wrote:
> On Fri, Apr 29, 2022 at 05:31:16PM +0000, Jon Kohler wrote:
> > Selftests IIUC, but there may be other VMMs that do funny stuff. Said
> > another way, I don’t think we actively restrict user space from doing
> > this as far as I know.
>
> "selftests", "there may be"?!
>
> This doesn't sound like a real-life use case to me and we don't do
> changes just because. Sorry.
>
> > The paranoid aspect here is KVM is issuing an *additional* IBPB on
> > top of what already happens in switch_mm().
>
> Yeah, I know how that works.
>
> > IMHO KVM side IBPB for most use cases isn’t really necessarily but
> > the general concept is that you want to protect vCPU from guest A
> > from guest B, so you issue a prediction barrier on vCPU switch.
> >
> > *however* that protection already happens in switch_mm(), because
> > guest A and B are likely to use different mm_struct, so the only point
> > of having this support in KVM seems to be to “kill it with fire” for
> > paranoid users who might be doing some tomfoolery that would
> > somehow bypass switch_mm() protection (such as somehow
> > sharing a struct).
>
> Yeah, no, this all sounds like something highly hypothetical or there's
> a use case of which you don't want to talk about publicly.
What Jon is trying to do is eliminate IBPB that already exists in KVM. The catch
is that, in theory, someone not-Jon could be running multiple VMs in a single
address space, e.g. VM-based containers. So if we simply delete the IBPB, then
we could theoretically and silently break a user. That's why there's a bunch of
hand-waving.
> Either way, from what I'm reading I'm not in the least convinced that
> this is needed.
Can you clarify what "this" is? Does "this" mean "this patch", or does it mean
"this IBPB when switching vCPUs"? Because if it means the latter, then I think
you're in violent agreement; the IBPB when switching vCPUs is pointless and
unnecessary.
next prev parent reply other threads:[~2022-04-29 20:29 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-04-22 16:21 [PATCH v3] x86/speculation, KVM: only IBPB for switch_mm_always_ibpb on vCPU load Jon Kohler
2022-04-28 12:51 ` Jon Kohler
2022-04-29 16:59 ` Borislav Petkov
2022-04-29 17:31 ` Jon Kohler
2022-04-29 19:32 ` Borislav Petkov
2022-04-29 20:08 ` Jon Kohler
2022-04-29 20:29 ` Sean Christopherson [this message]
2022-04-29 20:59 ` Borislav Petkov
2022-04-29 21:59 ` Sean Christopherson
2022-04-29 22:22 ` Borislav Petkov
2022-04-29 23:23 ` Sean Christopherson
2022-04-30 9:50 ` Borislav Petkov
2022-04-30 14:50 ` Jon Kohler
2022-04-30 16:08 ` Borislav Petkov
2022-05-06 15:42 ` Jon Kohler
2022-05-10 14:44 ` Sean Christopherson
2022-05-10 15:03 ` Jon Kohler
2022-05-10 15:50 ` Sean Christopherson
2022-05-12 13:44 ` Borislav Petkov
2022-05-12 17:56 ` Jon Kohler
2022-05-10 14:22 ` Sean Christopherson
2022-05-10 14:49 ` Jon Kohler
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=YmxKqpWFvdUv+GwJ@google.com \
--to=seanjc@google.com \
--cc=aarcange@redhat.com \
--cc=bp@alien8.de \
--cc=dave.hansen@linux.intel.com \
--cc=hpa@zytor.com \
--cc=jmattson@google.com \
--cc=jon@nutanix.com \
--cc=joro@8bytes.org \
--cc=jpoimboe@redhat.com \
--cc=keescook@chromium.org \
--cc=kim.phillips@amd.com \
--cc=kvm@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=longman@redhat.com \
--cc=mingo@redhat.com \
--cc=pbonzini@redhat.com \
--cc=peterz@infradead.org \
--cc=sblbir@amazon.com \
--cc=tglx@linutronix.de \
--cc=vkuznets@redhat.com \
--cc=wanpengli@tencent.com \
--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