All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sean Christopherson <sean.j.christopherson@intel.com>
To: Vitaly Kuznetsov <vkuznets@redhat.com>
Cc: kvm@vger.kernel.org, x86@kernel.org,
	Paolo Bonzini <pbonzini@redhat.com>,
	Thomas Gleixner <tglx@linutronix.de>,
	Ingo Molnar <mingo@redhat.com>, Borislav Petkov <bp@alien8.de>,
	Jim Mattson <jmattson@google.com>,
	Liran Alon <liran.alon@oracle.com>,
	linux-kernel@vger.kernel.org, "H. Peter Anvin" <hpa@zytor.com>,
	"Peter Zijlstra (Intel)" <peterz@infradead.org>
Subject: Re: [PATCH RFC] KVM: x86: tell guests if the exposed SMT topology is trustworthy
Date: Tue, 5 Nov 2019 15:25:00 -0800	[thread overview]
Message-ID: <20191105232500.GA25887@linux.intel.com> (raw)
In-Reply-To: <20191105193749.GA20225@linux.intel.com>

On Tue, Nov 05, 2019 at 11:37:50AM -0800, Sean Christopherson wrote:
> On Tue, Nov 05, 2019 at 05:17:37PM +0100, Vitaly Kuznetsov wrote:
> > Virtualized guests may pick a different strategy to mitigate hardware
> > vulnerabilities when it comes to hyper-threading: disable SMT completely,
> > use core scheduling, or, for example, opt in for STIBP. Making the
> > decision, however, requires an extra bit of information which is currently
> > missing: does the topology the guest see match hardware or if it is 'fake'
> > and two vCPUs which look like different cores from guest's perspective can
> > actually be scheduled on the same physical core. Disabling SMT or doing
> > core scheduling only makes sense when the topology is trustworthy.
> > 
> > Add two feature bits to KVM: KVM_FEATURE_TRUSTWORTHY_SMT with the meaning
> > that KVM_HINTS_TRUSTWORTHY_SMT bit answers the question if the exposed SMT
> > topology is actually trustworthy. It would, of course, be possible to get
> > away with a single bit (e.g. 'KVM_FEATURE_FAKE_SMT') and not lose backwards
> > compatibility but the current approach looks more straightforward.
> 
> I'd stay away from "trustworthy", especially if this is controlled by
> userspace.  Whether or not the hint is trustworthy is purely up to the
> guest.  Right now it doesn't really matter, but that will change as we
> start moving pieces of the host out of the guest's TCB.
> 
> It may make sense to split the two (or even three?) cases, e.g.
> KVM_FEATURE_NO_SMT and KVM_FEATURE_ACCURATE_TOPOLOGY.  KVM can easily
> enforce NO_SMT _today_, i.e. allow it to be set if and only if SMT is
> truly disabled.  Verifying that the topology exposed to the guest is legit
> is a completely different beast.

Scratch the ACCURATE_TOPOLOGY idea, I doubt there's a real use case for
setting ACCURATE_TOPOLOGY and not KVM_HINTS_REALTIME.  A feature flag to
state that SMT is disabled seems simple and useful.

  reply	other threads:[~2019-11-05 23:25 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-05 16:17 [PATCH RFC] KVM: x86: tell guests if the exposed SMT topology is trustworthy Vitaly Kuznetsov
2019-11-05 17:17 ` Liran Alon
2019-11-05 17:30   ` Liran Alon
2019-11-05 17:35     ` Jim Mattson
2019-11-05 19:37 ` Sean Christopherson
2019-11-05 23:25   ` Sean Christopherson [this message]
2019-11-07 10:38     ` Vitaly Kuznetsov
     [not found]     ` <943488A8-2DD7-4471-B3C7-9F21A0B0BCF9@dinechin.org>
2019-11-07 15:02       ` Liran Alon
2019-11-08 15:35         ` Christophe de Dinechin
2019-11-08 15:52           ` Liran Alon
2019-11-05 20:02 ` Peter Zijlstra
2019-11-05 23:25   ` Sean Christopherson
2019-11-06  8:32     ` Peter Zijlstra
2019-11-20 10:13       ` Wanpeng Li
2019-11-05 23:51   ` Paolo Bonzini
2019-11-06  8:32     ` Peter Zijlstra
2019-11-06  9:41       ` Paolo Bonzini
2019-11-05 23:56 ` Paolo Bonzini
2019-12-06  4:01   ` Ankur Arora
2019-12-06 13:46     ` Vitaly Kuznetsov
2019-12-06 20:31       ` Ankur Arora
2019-12-09  9:15         ` Paolo Bonzini

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=20191105232500.GA25887@linux.intel.com \
    --to=sean.j.christopherson@intel.com \
    --cc=bp@alien8.de \
    --cc=hpa@zytor.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=liran.alon@oracle.com \
    --cc=mingo@redhat.com \
    --cc=pbonzini@redhat.com \
    --cc=peterz@infradead.org \
    --cc=tglx@linutronix.de \
    --cc=vkuznets@redhat.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.