From: Sean Christopherson <seanjc@google.com>
To: Like Xu <like.xu.linux@gmail.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>,
Jim Mattson <jmattson@google.com>,
Wanpeng Li <wanpengli@tencent.com>,
Vitaly Kuznetsov <vkuznets@redhat.com>,
Joerg Roedel <joro@8bytes.org>,
x86@kernel.org, kvm@vger.kernel.org,
linux-kernel@vger.kernel.org
Subject: Re: [PATCH v2] KVM: x86/pt: Ignore all unknown Intel PT capabilities
Date: Tue, 11 Jan 2022 00:57:03 +0000 [thread overview]
Message-ID: <YdzV33X5w6+tCamI@google.com> (raw)
In-Reply-To: <20220110034747.30498-1-likexu@tencent.com>
On Mon, Jan 10, 2022, Like Xu wrote:
> From: Like Xu <likexu@tencent.com>
>
> Some of the new Intel PT capabilities (e.g. SDM Vol3, 32.2.4 Event
> Tracing, it exposes details about the asynchronous events, when they are
> generated, and when their corresponding software event handler completes
> execution) cannot be safely and fully emulated by the KVM, especially
> emulating the simultaneous writing of guest PT packets generated by
> the KVM to the guest PT buffer.
>
> For KVM, it's better to advertise currently supported features based on
> the "static struct pt_cap_desc" implemented in the host PT driver and
> ignore _all_ unknown features before they have been investigated one by
> one and supported in a safe manner, leaving the rest as system-wide-only
> tracing capabilities.
>
> Suggested-by: Paolo Bonzini <pbonzini@redhat.com>
> Signed-off-by: Like Xu <likexu@tencent.com>
> ---
> v1 -> v2 Changelog:
> - Be safe and ignore _all_ unknown capabilities. (Paolo)
>
> Previous:
> https://lore.kernel.org/kvm/20220106085533.84356-1-likexu@tencent.com/
>
> arch/x86/kvm/cpuid.c | 2 ++
> 1 file changed, 2 insertions(+)
>
> diff --git a/arch/x86/kvm/cpuid.c b/arch/x86/kvm/cpuid.c
> index 0b920e12bb6d..439b93359848 100644
> --- a/arch/x86/kvm/cpuid.c
> +++ b/arch/x86/kvm/cpuid.c
> @@ -901,6 +901,8 @@ static inline int __do_cpuid_func(struct kvm_cpuid_array *array, u32 function)
> break;
> }
>
> + /* It's better to be safe and ignore _all_ unknown capabilities. */
No need to justify why unknown capabilities are hidden as that's very much (supposed
to be) standard KVM behavior.
> + entry->ebx &= GENMASK(5, 0);
Please add a #define somewhere so that this is self-documenting, e.g. see
KVM_SUPPORTED_XCR0.
And why just EBX? ECX appears to enumerate features too, and EDX is presumably
reserved to enumerate yet more features when EBX/ECX run out of bits.
And is there any possibility of a malicious user/guest using features to cause
problems in the host? I.e. does KVM need to enforce that the guest can't enable
any unsupported features?
> for (i = 1, max_idx = entry->eax; i <= max_idx; ++i) {
> if (!do_host_cpuid(array, function, i))
> goto out;
> --
> 2.33.1
>
next prev parent reply other threads:[~2022-01-11 0:57 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-01-10 3:47 [PATCH v2] KVM: x86/pt: Ignore all unknown Intel PT capabilities Like Xu
2022-01-11 0:57 ` Sean Christopherson [this message]
2022-01-11 4:20 ` Like Xu
2022-01-11 6:24 ` Like Xu
2022-01-11 7:59 ` Xiaoyao Li
2022-01-11 8:15 ` Like Xu
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=YdzV33X5w6+tCamI@google.com \
--to=seanjc@google.com \
--cc=jmattson@google.com \
--cc=joro@8bytes.org \
--cc=kvm@vger.kernel.org \
--cc=like.xu.linux@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=pbonzini@redhat.com \
--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 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.