Received-SPF: pass (google.com: best guess record for domain of linux-kernel-owner@vger.kernel.org designates 209.132.180.67 as permitted sender) client-ip=209.132.180.67;
From:   Vitaly Kuznetsov <vkuznets@redhat.com>
To:     Sean Christopherson <sean.j.christopherson@intel.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
In-Reply-To: <20191105232500.GA25887@linux.intel.com>
References: <20191105161737.21395-1-vkuznets@redhat.com> <20191105193749.GA20225@linux.intel.com> <20191105232500.GA25887@linux.intel.com>
Date:   Thu, 07 Nov 2019 11:38:24 +0100
Message-ID: <87ftj0as4f.fsf@vitty.brq.redhat.com>
MIME-Version: 1.0
Content-Type: text/plain
Sender: linux-kernel-owner@vger.kernel.org
Precedence: bulk

Sean Christopherson <sean.j.christopherson@intel.com> writes:

> 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.

You seem to have the most conservative ideas around)

I wasn't actually thinking about KVM enforcing anything here, my goal
was to provide guest with enough information so it can adjust its SMT
related settings accordingly. These could be:
- 'nosmt'
- STIBP
- Core scheduling (not yet upstream afaik)
- Manual vCPU pinning for certain tasks (including running nested
guests). [E.g. nested Hyper-V hides 'md_clear' from its guests when it
doesn't see 'NoNonarchitecturalCoreSharing' from the underlying
hypervisor as it's pointless]
- (Liran's idea): Using SMT information for better scheduling

KVM_FEATURE_NO_SMT would cover one case, however, it's basically the
same as not exposing hyperthreads by KVM userspace, just enforced. Do
you think that such enforcement makes sense? What the guest is supposed
to do when it sees the flag (compared to what's doing now)?

('KVM_HINTS_REALTIME' may actually imply what we want, however, judging
by its name it may gain additional meaning in the future like 'always do
busy polling everywhere')

-- 
Vitaly