[Patch v2 1/9] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Patch v2 1/9] perf/x86/intel: Remove anythread_deprecated bit from perf_capabilities

[Dapeng Mi]

AnyThread mode deprecation is enumerated by CPUID.0AH:EDX[15] instead of
PERF_CAPABILITIES MSR. It's not a good practice to define a bit to
represent "anythread deprecation" in perf_capabilities. It leads to the
anythread_deprecated bit could be overwritten by the real value of
PERF_CAPABILITIES MSR, just like the below code in update_pmu_cap() does.

```
if (!intel_pmu_broken_perf_cap()) {
	/* Perf Metric (Bit 15) and PEBS via PT (Bit 16) are hybrid enumeration */
	rdmsrq(MSR_IA32_PERF_CAPABILITIES, hybrid(pmu, intel_cap).capabilities);
}
```

It leads to the anythread_deprecated bit is cleared to 0 and the "any"
attribute is incorrectly shown in the /sys/devices/cpu/format/ folder on
these support Perfmon v6 platforms, like Clearwater Forest.

```
$grep . /sys/devices/cpu/format/*
/sys/devices/cpu/format/acr_mask:config2:0-63
/sys/devices/cpu/format/any:config:21
/sys/devices/cpu/format/cmask:config:24-31
```

So remove the anythread_deprecated bit from perf_capabilities structure
and directly depends on CPUID.0AH:EDX[15] to judge if anythread is
deprecated.

Cc: stable@vger.kernel.org
Reported-by: Namhyung Kim <namhyung@kernel.org>
Fixes: cadbaa039b99 ("perf/x86/intel: Make anythread filter support conditional")
Acked-by: Namhyung Kim <namhyung@kernel.org>
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
Reviewed-by: Zide Chen <zide.chen@intel.com>
Reviewed-by: Thomas Falcon <thomas.falcon@intel.com>
---
 arch/x86/events/intel/core.c | 10 +++-------
 arch/x86/events/perf_event.h |  2 +-
 2 files changed, 4 insertions(+), 8 deletions(-)

diff --git a/arch/x86/events/intel/core.c b/arch/x86/events/intel/core.c
index 0217e701aeeb..ea3ab3050a3b 100644
--- a/arch/x86/events/intel/core.c
+++ b/arch/x86/events/intel/core.c
@@ -7946,12 +7946,6 @@ __init int intel_pmu_init(void)
 
 	x86_add_quirk(intel_arch_events_quirk); /* Install first, so it runs last */
 
-	if (version >= 5) {
-		x86_pmu.intel_cap.anythread_deprecated = edx.split.anythread_deprecated;
-		if (x86_pmu.intel_cap.anythread_deprecated)
-			pr_cont(" AnyThread deprecated, ");
-	}
-
 	/* The perf side of core PMU is ready to support the mediated vPMU. */
 	x86_get_pmu(smp_processor_id())->capabilities |= PERF_PMU_CAP_MEDIATED_VPMU;
 
@@ -8828,8 +8822,10 @@ __init int intel_pmu_init(void)
 				      &x86_pmu.intel_ctrl);
 
 	/* AnyThread may be deprecated on arch perfmon v5 or later */
-	if (x86_pmu.intel_cap.anythread_deprecated)
+	if (version >= 5 && edx.split.anythread_deprecated) {
 		x86_pmu.format_attrs = intel_arch_formats_attr;
+		pr_cont("AnyThread deprecated, ");
+	}
 
 	intel_pmu_check_event_constraints_all(NULL);
 
diff --git a/arch/x86/events/perf_event.h b/arch/x86/events/perf_event.h
index eae24bb35dc1..5902a297daa1 100644
--- a/arch/x86/events/perf_event.h
+++ b/arch/x86/events/perf_event.h
@@ -668,7 +668,7 @@ union perf_capabilities {
 		u64	perf_metrics:1;
 		u64	pebs_output_pt_available:1;
 		u64	pebs_timing_info:1;
-		u64	anythread_deprecated:1;
+		u64	__reserved:1;
 		u64	rdpmc_metrics_clear:1;
 	};
 	u64	capabilities;
-- 
2.34.1

[Patch v2 5/9] perf/x86/intel: Drop LBR entries whose privilege level mismatches br_sel

[Dapeng Mi]

Before Arch LBR gained CPL filtering support, a user-only branch stack
could still contain kernel addresses. As a result, kernel branch records
may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is
requested.

For example, on Intel Tiger Lake, the following command can still report
SYSRET/ERET entries with kernel-space from addresses:

```
$./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \
 	./perf bench syscall basic --loop 1000 | \
	./perf script -i - --fields brstack|tr ' ' '\n'| \
	grep -E '0x[89a-f][0-9a-f]{15}'

    Total time: 0.000 [sec]

      0.219000 usecs/op
     4,566,210 ops/sec
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 0.551 MB - ]
0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/-
0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/-
0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/-
0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/-
```

The problem is that intel_pmu_lbr_filter() does not fully validate the
privilege level of sampled entries. It filters some mismatches based on
the branch type and the to address, but it does not reject entries whose
from address violates the requested branch privilege filter.

Fix this by extending software filtering to validate both from and to
addresses against br_sel. Any LBR entry whose privilege level does not
match the requested user/kernel filter is dropped. This prevents kernel
addresses from appearing in user-only branch stacks, and likewise drops
user entries from kernel-only stacks.

Cc: stable@vger.kernel.org
Reported-by: Ian Rogers <irogers@google.com>
Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
---
 arch/x86/events/intel/lbr.c | 14 +++++++++++---
 1 file changed, 11 insertions(+), 3 deletions(-)

diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
index d4c0ed85e1fb..807ce903c972 100644
--- a/arch/x86/events/intel/lbr.c
+++ b/arch/x86/events/intel/lbr.c
@@ -1212,7 +1212,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
 {
 	u64 from, to;
 	int br_sel = cpuc->br_sel;
-	int i, j, type, to_plm;
+	int i, j, type, to_plm, from_plm;
 	bool compress = false;
 
 	/* if sampling all branches, then nothing to filter */
@@ -1245,8 +1245,16 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
 				type |= X86_BR_NO_TX;
 		}
 
-		/* if type does not correspond, then discard */
-		if (type == X86_BR_NONE || (br_sel & type) != type) {
+		from_plm = kernel_ip(from) ? X86_BR_KERNEL : X86_BR_USER;
+		/*
+		 * If type does not correspond, then discard.
+		 * Especially filter out the entries whose from or to address is
+		 * a kernel address while only X86_BR_USER is set. This prevents
+		 * kernel address from being leaked into a user-space-only LBR stack.
+		 */
+		if (type == X86_BR_NONE || (br_sel & type) != type ||
+		    (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL)) ||
+		    (!(br_sel & X86_BR_USER) && (from_plm & X86_BR_USER))) {
 			cpuc->lbr_entries[i].from = 0;
 			compress = true;
 		}
-- 
2.34.1

Re: [Patch v2 5/9] perf/x86/intel: Drop LBR entries whose privilege level mismatches br_sel

[Peter Zijlstra]

On Tue, Jun 09, 2026 at 01:02:18PM +0800, Dapeng Mi wrote:
> Before Arch LBR gained CPL filtering support, a user-only branch stack
> could still contain kernel addresses. As a result, kernel branch records
> may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is
> requested.
> 
> For example, on Intel Tiger Lake, the following command can still report
> SYSRET/ERET entries with kernel-space from addresses:
> 
> ```
> $./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \
>  	./perf bench syscall basic --loop 1000 | \
> 	./perf script -i - --fields brstack|tr ' ' '\n'| \
> 	grep -E '0x[89a-f][0-9a-f]{15}'
> 
>     Total time: 0.000 [sec]
> 
>       0.219000 usecs/op
>      4,566,210 ops/sec
> [ perf record: Woken up 1 times to write data ]
> [ perf record: Captured and wrote 0.551 MB - ]
> 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/-
> 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/-
> 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/-
> 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/-
> ```
> 
> The problem is that intel_pmu_lbr_filter() does not fully validate the
> privilege level of sampled entries. It filters some mismatches based on
> the branch type and the to address, but it does not reject entries whose
> from address violates the requested branch privilege filter.
> 
> Fix this by extending software filtering to validate both from and to
> addresses against br_sel. Any LBR entry whose privilege level does not
> match the requested user/kernel filter is dropped. This prevents kernel
> addresses from appearing in user-only branch stacks, and likewise drops
> user entries from kernel-only stacks.
> 
> Cc: stable@vger.kernel.org
> Reported-by: Ian Rogers <irogers@google.com>
> Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
> ---
>  arch/x86/events/intel/lbr.c | 14 +++++++++++---
>  1 file changed, 11 insertions(+), 3 deletions(-)
> 
> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
> index d4c0ed85e1fb..807ce903c972 100644
> --- a/arch/x86/events/intel/lbr.c
> +++ b/arch/x86/events/intel/lbr.c
> @@ -1212,7 +1212,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
>  {
>  	u64 from, to;
>  	int br_sel = cpuc->br_sel;
> -	int i, j, type, to_plm;
> +	int i, j, type, to_plm, from_plm;
>  	bool compress = false;
>  
>  	/* if sampling all branches, then nothing to filter */

If there, might as well order those variables in reverse xmas.

Re: [Patch v2 5/9] perf/x86/intel: Drop LBR entries whose privilege level mismatches br_sel

[Mi, Dapeng]

On 6/9/2026 10:52 PM, Peter Zijlstra wrote:
> On Tue, Jun 09, 2026 at 01:02:18PM +0800, Dapeng Mi wrote:
>> Before Arch LBR gained CPL filtering support, a user-only branch stack
>> could still contain kernel addresses. As a result, kernel branch records
>> may be exposed to user space even when PERF_SAMPLE_BRANCH_USER is
>> requested.
>>
>> For example, on Intel Tiger Lake, the following command can still report
>> SYSRET/ERET entries with kernel-space from addresses:
>>
>> ```
>> $./perf record -e cycles:p -o - --branch-filter any,save_type,u -- \
>>  	./perf bench syscall basic --loop 1000 | \
>> 	./perf script -i - --fields brstack|tr ' ' '\n'| \
>> 	grep -E '0x[89a-f][0-9a-f]{15}'
>>
>>     Total time: 0.000 [sec]
>>
>>       0.219000 usecs/op
>>      4,566,210 ops/sec
>> [ perf record: Woken up 1 times to write data ]
>> [ perf record: Captured and wrote 0.551 MB - ]
>> 0xffffffff93c001c8/0x7f12a2b1d647/P/-/-/16959/SYSRET/-
>> 0xffffffff93c001c8/0x7f12a2b1d5c2/P/-/-/17535/SYSRET/-
>> 0xffffffff93c01928/0x7f12a2861000/P/-/-/6719/ERET/-
>> 0xffffffff93c01928/0x7f12a297a000/P/-/-/8575/ERET/-
>> ```
>>
>> The problem is that intel_pmu_lbr_filter() does not fully validate the
>> privilege level of sampled entries. It filters some mismatches based on
>> the branch type and the to address, but it does not reject entries whose
>> from address violates the requested branch privilege filter.
>>
>> Fix this by extending software filtering to validate both from and to
>> addresses against br_sel. Any LBR entry whose privilege level does not
>> match the requested user/kernel filter is dropped. This prevents kernel
>> addresses from appearing in user-only branch stacks, and likewise drops
>> user entries from kernel-only stacks.
>>
>> Cc: stable@vger.kernel.org
>> Reported-by: Ian Rogers <irogers@google.com>
>> Fixes: 47125db27e47 ("perf/x86/intel/lbr: Support Architectural LBR")
>> Signed-off-by: Dapeng Mi <dapeng1.mi@linux.intel.com>
>> ---
>>  arch/x86/events/intel/lbr.c | 14 +++++++++++---
>>  1 file changed, 11 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>> index d4c0ed85e1fb..807ce903c972 100644
>> --- a/arch/x86/events/intel/lbr.c
>> +++ b/arch/x86/events/intel/lbr.c
>> @@ -1212,7 +1212,7 @@ intel_pmu_lbr_filter(struct cpu_hw_events *cpuc)
>>  {
>>  	u64 from, to;
>>  	int br_sel = cpuc->br_sel;
>> -	int i, j, type, to_plm;
>> +	int i, j, type, to_plm, from_plm;
>>  	bool compress = false;
>>  
>>  	/* if sampling all branches, then nothing to filter */
> If there, might as well order those variables in reverse xmas.

Sure. Thanks.