mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Chen, Zide" <zide.chen@intel.com>
To: "Mi, Dapeng" <dapeng1.mi@linux.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: Thu, 30 Jul 2026 10:05:01 -0500	[thread overview]
Message-ID: <f8f9fc13-fafc-4828-ad5b-79e3677d9536@intel.com> (raw)
In-Reply-To: <a6481eb0-0480-41f2-97c3-ab5f278f7e50@linux.intel.com>



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.


>> +}
>> +
>>  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-30 15:05 UTC|newest]

Thread overview: 18+ 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:21 ` [PATCH v7 3/9] KVM: x86/pmu: Rename and move vcpu_get_perf_capabilities() to pmu.h Zide Chen
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:21 ` [PATCH v7 5/9] KVM: x86/pmu: Support PERF_METRICS MSR in mediated vPMU Zide Chen
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-30  2:51   ` Mi, Dapeng
2026-07-30 15:05     ` Chen, Zide [this message]
2026-07-31  0:50       ` Mi, Dapeng
2026-07-30 15:11     ` Jim Mattson
2026-07-31  1:03       ` Mi, Dapeng
2026-07-31  1:12   ` Mi, Dapeng
2026-07-31 20:28     ` Chen, Zide
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=f8f9fc13-fafc-4828-ad5b-79e3677d9536@intel.com \
    --to=zide.chen@intel.com \
    --cc=Manali.Shukla@amd.com \
    --cc=Sandipan.Das@amd.com \
    --cc=ak@linux.intel.com \
    --cc=dapeng1.mi@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 \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®