[PATCH] perf/x86/amd/lbr: Fix kernel address leakage

[PATCH] perf/x86/amd/lbr: Fix kernel address leakage

[Sandipan Das]

A user-only branch stack can contain branches that originate from
the kernel. As a result, kernel addresses are exposed to user space
even when PERF_SAMPLE_BRANCH_USER is requested. On AMD processors
supporting X86_FEATURE_AMD_LBR_V2, perf can still report SYSRET/ERET
entries for which the branch-from addresses are in the kernel.

E.g.

  $ perf record -e cycles -o - -j any,save_type,u -- \
        perf bench syscall basic --loop 1000 | \
        perf script -i - -F brstack|tr ' ' '\n'| \
        grep -E '0x[89a-f][0-9a-f]{15}'

  ...
  0xffffffff81001268/0x717a90a38f1a/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  0xffffffff81001268/0x717a90a39157/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  0xffffffff81001268/0x717a90a2c628/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  0xffffffff81001268/0x717a90a41b60/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  0xffffffff81001268/0x717a90a260db/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  0xffffffff81001268/0x717a8bef1c30/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  0xffffffff81001268/0x717a8e4d3c90/M/-/-/0/ERET/NON_SPEC_CORRECT_PATH
  ...

The reason is that the hardware filter only considers the privilege
level applicable to the branch target. Extend software filtering to
also validate the branch-from addresses against br_sel, so that any
branch record whose branch-from address is in the kernel is dropped
when PERF_SAMPLE_BRANCH_USER is requested.

Fixes: f4f925dae741 ("perf/x86/amd/lbr: Add LbrExtV2 hardware branch filter support")
Reported-by: Ian Rogers <irogers@google.com>
Signed-off-by: Sandipan Das <sandipan.das@amd.com>
---
 arch/x86/events/amd/lbr.c | 3 ++-
 1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
index 5b437dc8e4ce..9d9c961989d5 100644
--- a/arch/x86/events/amd/lbr.c
+++ b/arch/x86/events/amd/lbr.c
@@ -127,7 +127,8 @@ static void amd_pmu_lbr_filter(void)
 		}
 
 		/* If type does not correspond, then discard */
-		if (type == X86_BR_NONE || (br_sel & type) != type) {
+		if (type == X86_BR_NONE || (br_sel & type) != type ||
+		    (!(br_sel & X86_BR_KERNEL) && kernel_ip(cpuc->lbr_entries[i].from))) {
 			cpuc->lbr_entries[i].from = 0;	/* mark invalid */
 			compress = true;
 		}
-- 
2.53.0

Re: [PATCH] perf/x86/amd/lbr: Fix kernel address leakage

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:

Pre-existing issues:
- [High] AMD's Branch Record Sampling (BRS) software filter shares the exact same logic flaw as AMD LBR V2, exposing kernel addresses when PERF_SAMPLE_BRANCH_USER is requested.
- [High] The Intel LBR software filter shares the same logic flaw, exposing kernel addresses on Intel CPUs that rely on software filtering.
--

--- Patch [1]: [PATCH] perf/x86/amd/lbr: Fix kernel address leakage ---
commit f8aba9338ad1990ca06ee1ac10089bd82793534b
Author: Sandipan Das <sandipan.das@amd.com>

perf/x86/amd/lbr: Fix kernel address leakage

A user-only branch stack can contain branches that originate from the kernel,
exposing kernel addresses to user space even when PERF_SAMPLE_BRANCH_USER
is requested. This commit extends software filtering on AMD processors
supporting X86_FEATURE_AMD_LBR_V2 to validate branch-from addresses against
the requested branch selection, dropping entries with kernel branch-from
addresses.

> diff --git a/arch/x86/events/amd/lbr.c b/arch/x86/events/amd/lbr.c
> index d24da377df776..b9722e60d8bc7 100644
> --- a/arch/x86/events/amd/lbr.c
> +++ b/arch/x86/events/amd/lbr.c
> @@ -125,7 +125,8 @@ static void amd_pmu_lbr_filter(void)
>  		}
>  
>  		/* If type does not correspond, then discard */
> -		if (type == X86_BR_NONE || (br_sel & type) != type) {
> +		if (type == X86_BR_NONE || (br_sel & type) != type ||
> +		    (!(br_sel & X86_BR_KERNEL) && kernel_ip(cpuc->lbr_entries[i].from))) {

[Severity: High]
This isn't a bug introduced by this patch, but does the AMD Branch Record
Sampling (BRS) software filter share this exact same logic flaw?

Looking at arch/x86/events/amd/brs.c:amd_brs_match_plm():

        if (!(type & plm_k) && kernel_ip(to))
                return false;

The software privilege filter evaluates only the target address (to) but
fails to validate the source address (from). When amd_brs_drain() reads
the unfiltered kernel 'from' address:

        rdmsrq(brs_from(brs_idx), from);

Could this allow kernel-to-user transitions to pass and leak kernel addresses
when PERF_SAMPLE_BRANCH_USER is requested?


[Severity: High]
This is also a pre-existing issue not introduced by this patch, but does the
Intel LBR software filter have the same vulnerability?

Looking at arch/x86/events/intel/lbr.c:intel_pmu_lbr_filter():

        to_plm = kernel_ip(to) ? X86_BR_KERNEL : X86_BR_USER;
        type = arch_lbr_br_type_map[type] | to_plm;

The branch type's privilege level is determined exclusively by the target
address (to), ignoring the source address (from). When it checks the type
later in the same function:

        if (type == X86_BR_NONE || (br_sel & type) != type) {
                cpuc->lbr_entries[i].from = 0;
                compress = true;
        }

It seems this would also fail to filter out kernel-to-user branches when
PERF_SAMPLE_BRANCH_USER is requested. Should similar software filtering
be applied there to validate the branch-from addresses?

>  			cpuc->lbr_entries[i].from = 0;	/* mark invalid */
>  			compress = true;
>  		}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/a898a29725f6b2f30518354cdc2e432db66c43cf.1783680119.git.sandipan.das@amd.com?part=1