Re: [PATCH 2/2] perf/x86/intel: Fix kernel address leakages in LBR stack

["Mi, Dapeng" <dapeng1.mi@linux.intel.com>]

On 4/30/2026 4:57 AM, Chen, Zide wrote:
>
> On 4/13/2026 7:14 PM, Dapeng Mi wrote:
>> Prior to the arch-LBR which supports CPL filtering, the kernel address
>> could be leaked to user space even PERF_SAMPLE_BRANCH_USER is required.
> This sounds correct to catch these branches, since only the target CPL
> counts. The software filtering is implemented to match the HW behavior:
>
> Legacy LBR.
> CPL_EQ_0: When set, do not capture branches ending in ring 0
> CPL_NEQ_0: When set, do not capture branches ending in ring >0
>
> Arch LBR:
> For operations which change the CPL, the operation is recorded in LBRs
> only if the CPL at the end of the operation is enabled for LBR
> recording. In cases where the CPL transitions from a value that is
> filtered out to a value that is enabled for LBR
> recording, the FROM_IP address for the recorded CPL transition branch or
> event will be 0FFFFFFFFFFFFFFFFH.

Yes, this is exactly what HW does.


>
>> e.g., run below command on Intel Tigerlake platform,
>>
>> ```
>> $./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/-
>> ```
> Thus, filtering with USR=1, it's correct that ERET/SYSRET show up in the
> above command running on TG because the target CPL is 3. However, the
> from address should be hidden with 0xFFFFFFFFFFFFFFFF.

Hmm, in theory forcing the "from" IP to 0xFFFFFFFFFFFFFFFF seems a better
idea, don't lose SYSRET/ERET trace and no kernel address leakage as well.

It works for legacy LBR, but arch-LBR HW already forces the "from" IP to
0xFFFFFFFFFFFFFFFF , SW has no way to figure out the real branch type, so
the branch type has to be converted X86_BR_NONE which leads to this entry
is dropped.

Beside, I'm not sure if this would break current test case. @Ian, how's
your idea on this?


>
> Instead, this appears a bug on platforms with CPL filtering (SPR, etc.)
> that filters out these branches. This is because for ERET/SYSRET, the
> br_type is 8 (OTHER_BRANCH), so even on arch LBR, it gets the type from
> branch_type() which incorrectly translates type 8 to 0 (X86_BR_NONE).

As above explained, this doesn't work for arch-LBR.

Thanks.


>
> Therefore, something needs to be done in get_branch_type() to handle
> OTHER_BRANCH.
>
>> The SYSRET/ERET branch calls are found the in the LBR stack, whose "from"
>> addresses are obviously kernel address.
>>
>> Currently intel_pmu_lbr_filter() only filters out the LBR entries whose
>> "to" address is a kernel address but doesn't check the "from" address.
>>
>> To fix the issue, extend the software filtering to both "from" and "to"
>> addresses.
>>
>> 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 | 13 ++++++++++---
>>  1 file changed, 10 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/x86/events/intel/lbr.c b/arch/x86/events/intel/lbr.c
>> index 16977e4c6f8a..deef81c16571 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 */
>> @@ -1244,8 +1244,15 @@ 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_PLM) == 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_PLM) == X86_BR_NONE || (br_sel & type) != type ||
>> +		    (!(br_sel & X86_BR_KERNEL) && (from_plm & X86_BR_KERNEL))) {
>>  			cpuc->lbr_entries[i].from = 0;
>>  			compress = true;
>>  		}