linux-kernel - Re: [PATCH v2 6/7] KVM: VMX: Check Intel PT related CPUID leaves

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <YW2uUcor5nhDZ3DS@google.com>
Date:   Mon, 18 Oct 2021 17:26:41 +0000
From:   Sean Christopherson <seanjc@...gle.com>
To:     Xiaoyao Li <xiaoyao.li@...el.com>
Cc:     Paolo Bonzini <pbonzini@...hat.com>,
        Vitaly Kuznetsov <vkuznets@...hat.com>,
        Wanpeng Li <wanpengli@...cent.com>,
        Jim Mattson <jmattson@...gle.com>,
        Joerg Roedel <joro@...tes.org>, kvm@...r.kernel.org,
        linux-kernel@...r.kernel.org
Subject: Re: [PATCH v2 6/7] KVM: VMX: Check Intel PT related CPUID leaves

On Mon, Oct 18, 2021, Xiaoyao Li wrote:
> On 10/18/2021 8:47 PM, Paolo Bonzini wrote:
> > > > One option would be to bump that to the theoretical max of 15,
> > > > which doesn't seem too horrible, especially if pt_desc as a whole
> > > > is allocated on-demand, which it probably should be since it isn't
> > > > exactly tiny (nor ubiquitous)
> > > > 
> > > > A different option would be to let userspace define whatever it
> > > > wants for guest CPUID, and instead cap nr_addr_ranges at
> > > > min(host.cpuid, guest.cpuid, RTIT_ADDR_RANGE).
> > 
> > This is the safest option.
> 
> My concern was that change userspace's input silently is not good.

Technically KVM isn't changing userspace's input, as KVM will still enumerate
CPUID as defined by userspace.  What KVM is doing is refusing to emulate/virtualize
a bogus vCPU model, e.g. by injecting #GP on an MSR access that userspace
incorrectly told the guest was legal.  That is standard operation procedure for
KVM, e.g. there are any number of instructions that will fault if userspace lies
about the vCPU model.

> prefer this, we certainly need to extend the userspace to query what value
> is finally accepted and set by KVM.

That would be __do_cpuid_func()'s responsibility to cap leaf 0x14 output with
RTIT_ADDR_RANGE.  I.e. enumerate the supported ranges in KVM_GET_SUPPORTED_CPUID,
after that it's userspace's responsibility to not mess up.