All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Mi, Dapeng" <dapeng1.mi@linux.intel.com>
To: "Chen, Zide" <zide.chen@intel.com>,
	Sean Christopherson <seanjc@google.com>,
	Paolo Bonzini <pbonzini@redhat.com>
Cc: kvm@vger.kernel.org, Jim Mattson <jmattson@google.com>,
	Andi Kleen <ak@linux.intel.com>,
	linux-kernel@vger.kernel.org, Mingwei Zhang <mizhang@google.com>,
	Das Sandipan <Sandipan.Das@amd.com>,
	Shukla Manali <Manali.Shukla@amd.com>,
	Falcon Thomas <thomas.falcon@intel.com>,
	Xudong Hao <xudong.hao@intel.com>
Subject: Re: [PATCH v7 7/9] KVM: x86/pmu: Restrict RDPMC passthrough to known CPUs
Date: Fri, 31 Jul 2026 08:50:17 +0800	[thread overview]
Message-ID: <b96073d4-6e6e-4188-bcee-5ff0feeebc96@linux.intel.com> (raw)
In-Reply-To: <f8f9fc13-fafc-4828-ad5b-79e3677d9536@intel.com>


On 7/30/2026 11:05 PM, Chen, Zide wrote:
>
> On 7/29/2026 9:51 PM, Mi, Dapeng wrote:
>> On 7/28/2026 3:21 AM, Zide Chen wrote:
>>> RDPMC type encodings are vendor-defined and could theoretically be
>>> extended on future CPUs. An unknown RDPMC type could leak host
>>> PMU information to the guest through RDPMC passthrough.
>>>
>>> Rather than assuming future CPUs are safe, explicitly permit only
>>> reviewed CPU models and require RDPMC interception everywhere else.
>>> This ensures RDPMC passthrough is enabled only on CPUs whose RDPMC
>>> encodings are audited and supported by KVM.
>>>
>>> Suggested-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>>> Suggested-by: Jim Mattson <jmattson@google.com>
>>> Signed-off-by: Zide Chen <zide.chen@intel.com>
>>> ---
>>> v7: new patch.
>>> ---
>>>  arch/x86/kvm/pmu.c | 32 ++++++++++++++++++++++++++++++++
>>>  1 file changed, 32 insertions(+)
>>>
>>> diff --git a/arch/x86/kvm/pmu.c b/arch/x86/kvm/pmu.c
>>> index 51c6d00a485f..092809bd757d 100644
>>> --- a/arch/x86/kvm/pmu.c
>>> +++ b/arch/x86/kvm/pmu.c
>>> @@ -77,6 +77,21 @@ static const struct x86_cpu_id vmx_pebs_pdist_cpu[] = {
>>>  	{}
>>>  };
>>>  
>>> +/*
>>> + * CPUs whose RDPMC encodings have been audited for KVM RDPMC
>>> + * passthrough support.
>>> + */
>>> +static const struct x86_cpu_id kvm_rdpmc_known_cpus[] = {
>>> +	X86_MATCH_VFM(INTEL_ATOM_DARKMONT_X, NULL),
>>> +	X86_MATCH_VFM(INTEL_LUNARLAKE_M, NULL),
>>> +	X86_MATCH_VFM(INTEL_NOVALAKE, NULL),
>>> +	X86_MATCH_VFM(INTEL_NOVALAKE_L, NULL),
>>> +	X86_MATCH_VFM(INTEL_PANTHERLAKE_L, NULL),
>>> +	X86_MATCH_VFM(INTEL_PANTHERLAKE_R, NULL),
>>> +	X86_MATCH_VFM(INTEL_WILDCATLAKE_L, NULL),
>>> +	{}
>>> +};
>>> +
>>>  /* NOTE:
>>>   * - Each perf counter is defined as "struct kvm_pmc";
>>>   * - There are two types of perf counters: general purpose (gp) and fixed.
>>> @@ -807,6 +822,20 @@ bool kvm_need_perf_global_ctrl_intercept(struct kvm_vcpu *vcpu)
>>>  }
>>>  EXPORT_SYMBOL_FOR_KVM_INTERNAL(kvm_need_perf_global_ctrl_intercept);
>>>  
>>> +static bool kvm_rdpmc_encoding_supported(void)
>>> +{
>>> +	/* KVM understands all RDPMC encodings prior to PMU v6. */
>>> +	if (kvm_host_pmu.version < 6)
>> I'm not sure if this works for AMD platforms. Jim said current AMD
>> platforms already have security holes and I believe the PMU version of AMD
>> platforms are less than 6.
>>
>> Need AMD guys to confirm. @Sandipan, @Manali.
>>
>>
>>> +		return true;
>>> +
>>> +	/*
>>> +	 * Future PMU v6 implementations and future PMU versions require RDPMC
>>> +	 * interception until their RDPMC encodings are audited and supported
>>> +	 * by KVM.
>>> +	 */
>>> +	return x86_match_cpu(kvm_rdpmc_known_cpus);
>> x86_match_cpu() returns structure x86_cpu_id pointer or NULL instead of a
>> boolean variable. Better explicitly covert it to a boolean variable.
>>
>> return x86_match_cpu(kvm_rdpmc_known_cpus) != NULL;
> I think the implicit conversion is valid here. In C99, implicit
> conversion from a pointer to bool is well-defined, and is commonly used,
> e.g. if (x86_match_cpu(...)).
>
> bool is a typedef of _Bool.
>
> C99 6.3.1.2 "Boolean type":
>
> When any scalar value is converted to _Bool, the result is 0 if the
> value compares equal to 0; otherwise the result is 1.

Yeah, the implicit conversion is fine in theory. But the explicit
conversion seems more intuitionistic for me. Anyway, you can decide which
way you want. :)


>
>
>>> +}
>>> +
>>>  bool kvm_need_rdpmc_intercept(struct kvm_vcpu *vcpu)
>>>  {
>>>  	struct kvm_pmu *pmu = vcpu_to_pmu(vcpu);
>>> @@ -818,6 +847,9 @@ bool kvm_need_rdpmc_intercept(struct kvm_vcpu *vcpu)
>>>  	if (enable_vmware_backdoor)
>>>  		return true;
>>>  
>>> +	if (!kvm_rdpmc_encoding_supported())
>>> +		return true;
>>> +
>>>  	return kvm_need_any_pmc_intercept(vcpu) ||
>>>  	       pmu->counter_bitmask[KVM_PMC_GP] != (BIT_ULL(kvm_host_pmu.bit_width_gp) - 1) ||
>>>  	       pmu->counter_bitmask[KVM_PMC_FIXED] != (BIT_ULL(kvm_host_pmu.bit_width_fixed) - 1);
>

  reply	other threads:[~2026-07-31  0:50 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-07-27 19:21 [PATCH v7 0/9] KVM: x86/pmu: Add hardware Topdown metrics support Zide Chen
2026-07-27 19:21 ` [PATCH v7 1/9] KVM: x86/pmu: Do not map fixed counters >= 3 to generic perf events Zide Chen
2026-07-27 19:21 ` [PATCH v7 2/9] KVM: x86/pmu: Support Intel fixed counter 3 on mediated vPMU Zide Chen
2026-07-27 19:51   ` sashiko-bot
2026-07-27 22:44     ` Chen, Zide
2026-07-27 19:21 ` [PATCH v7 3/9] KVM: x86/pmu: Rename and move vcpu_get_perf_capabilities() to pmu.h Zide Chen
2026-07-27 19:42   ` sashiko-bot
2026-07-27 22:19     ` Chen, Zide
2026-07-27 19:21 ` [PATCH v7 4/9] KVM: x86/pmu: Snapshot host IA32_PERF_CAPABILITIES in kvm_host Zide Chen
2026-07-27 19:44   ` sashiko-bot
2026-07-27 23:16     ` Chen, Zide
2026-07-27 19:21 ` [PATCH v7 5/9] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU Zide Chen
2026-07-27 19:50   ` sashiko-bot
2026-07-27 23:55     ` Chen, Zide
2026-07-27 19:21 ` [PATCH v7 6/9] KVM: x86/pmu: Move RDPMC emulation into per-vendor callbacks Zide Chen
2026-07-27 19:21 ` [PATCH v7 7/9] KVM: x86/pmu: Restrict RDPMC passthrough to known CPUs Zide Chen
2026-07-27 19:41   ` sashiko-bot
2026-07-27 21:41     ` Chen, Zide
2026-07-30  2:51   ` Mi, Dapeng
2026-07-30 15:05     ` Chen, Zide
2026-07-31  0:50       ` Mi, Dapeng [this message]
2026-07-30 15:11     ` Jim Mattson
2026-07-31  1:03       ` Mi, Dapeng
2026-07-31  1:12   ` Mi, Dapeng
2026-07-27 19:21 ` [PATCH v7 8/9] KVM: x86/pmu: Emulate RDPMC on performance metrics Zide Chen
2026-07-27 19:21 ` [PATCH v7 9/9] KVM: selftests: Add PERF_METRICS and fixed counter 3 tests Zide Chen
2026-07-30  2:58   ` Mi, Dapeng

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=b96073d4-6e6e-4188-bcee-5ff0feeebc96@linux.intel.com \
    --to=dapeng1.mi@linux.intel.com \
    --cc=Manali.Shukla@amd.com \
    --cc=Sandipan.Das@amd.com \
    --cc=ak@linux.intel.com \
    --cc=jmattson@google.com \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mizhang@google.com \
    --cc=pbonzini@redhat.com \
    --cc=seanjc@google.com \
    --cc=thomas.falcon@intel.com \
    --cc=xudong.hao@intel.com \
    --cc=zide.chen@intel.com \
    /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.