public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <seanjc@google.com>
To: Jon Kohler <jon@nutanix.com>
Cc: Jonathan Corbet <corbet@lwn.net>,
	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>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Dave Hansen <dave.hansen@linux.intel.com>,
	x86@kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	Kees Cook <keescook@chromium.org>,
	Andrea Arcangeli <aarcange@redhat.com>,
	Josh Poimboeuf <jpoimboe@redhat.com>,
	Kim Phillips <kim.phillips@amd.com>,
	Lukas Bulwahn <lukas.bulwahn@gmail.com>,
	Peter Zijlstra <peterz@infradead.org>,
	Ashok Raj <ashok.raj@intel.com>,
	KarimAllah Ahmed <karahmed@amazon.de>,
	David Woodhouse <dwmw@amazon.co.uk>,
	linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
	kvm@vger.kernel.org, Waiman Long <longman@redhat.com>
Subject: Re: [PATCH v4] x86/speculation, KVM: remove IBPB on vCPU load
Date: Thu, 12 May 2022 19:35:16 +0000	[thread overview]
Message-ID: <Yn1hdHgMVuni/GEx@google.com> (raw)
In-Reply-To: <Yn1fjAqFoszWz500@google.com>

On Thu, May 12, 2022, Sean Christopherson wrote:
> On Thu, May 12, 2022, Jon Kohler wrote:
> > Remove IBPB that is done on KVM vCPU load, as the guest-to-guest
> > attack surface is already covered by switch_mm_irqs_off() ->
> > cond_mitigation().
> > 
> > The original commit 15d45071523d ("KVM/x86: Add IBPB support") was simply
> > wrong in its guest-to-guest design intention. There are three scenarios
> > at play here:
> 
> Jim pointed offline that there's a case we didn't consider.  When switching between
> vCPUs in the same VM, an IBPB may be warranted as the tasks in the VM may be in
> different security domains.  E.g. the guest will not get a notification that vCPU0 is
> being swapped out for vCPU1 on a single pCPU.
> 
> So, sadly, after all that, I think the IBPB needs to stay.  But the documentation
> most definitely needs to be updated.
> 
> A per-VM capability to skip the IBPB may be warranted, e.g. for container-like
> use cases where a single VM is running a single workload.

Ah, actually, the IBPB can be skipped if the vCPUs have different mm_structs,
because then the IBPB is fully redundant with respect to any IBPB performed by
switch_mm_irqs_off().  Hrm, though it might need a KVM or per-VM knob, e.g. just
because the VMM doesn't want IBPB doesn't mean the guest doesn't want IBPB.

That would also sidestep the largely theoretical question of whether vCPUs from
different VMs but the same address space are in the same security domain.  It doesn't
matter, because even if they are in the same domain, KVM still needs to do IBPB.

  reply	other threads:[~2022-05-12 19:35 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-05-12 18:45 [PATCH v4] x86/speculation, KVM: remove IBPB on vCPU load Jon Kohler
2022-05-12 19:27 ` Sean Christopherson
2022-05-12 19:35   ` Sean Christopherson [this message]
2022-05-12 19:51     ` Jon Kohler
2022-05-12 20:06       ` Jim Mattson
2022-05-12 20:07       ` Sean Christopherson
2022-05-12 20:27         ` Jim Mattson
2022-05-12 20:33           ` Jon Kohler
2022-05-12 23:57             ` Jim Mattson
2022-05-13  0:50               ` Jon Kohler
2022-05-13  3:06                 ` Jim Mattson
2022-05-13  3:19                   ` Jon Kohler
2022-05-13  3:50                     ` Jim Mattson
2022-05-13 15:21                       ` Jon Kohler
2022-05-13 19:36                         ` Jim Mattson
2022-05-12 20:31         ` 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=Yn1hdHgMVuni/GEx@google.com \
    --to=seanjc@google.com \
    --cc=aarcange@redhat.com \
    --cc=ashok.raj@intel.com \
    --cc=bp@alien8.de \
    --cc=corbet@lwn.net \
    --cc=dave.hansen@linux.intel.com \
    --cc=dwmw@amazon.co.uk \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=jon@nutanix.com \
    --cc=joro@8bytes.org \
    --cc=jpoimboe@redhat.com \
    --cc=karahmed@amazon.de \
    --cc=keescook@chromium.org \
    --cc=kim.phillips@amd.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=longman@redhat.com \
    --cc=lukas.bulwahn@gmail.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --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