[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <7c9a00c3-b2a0-4f8a-945b-cc90e492988a@amd.com>
Date: Sat, 22 Mar 2025 15:45:28 +0530
From: Ravi Bangoria <ravi.bangoria@....com>
To: Ingo Molnar <mingo@...nel.org>
Cc: peterz@...radead.org, namhyung@...nel.org, mingo@...hat.com,
acme@...nel.org, kan.liang@...ux.intel.com, mark.rutland@....com,
alexander.shishkin@...ux.intel.com, linux-kernel@...r.kernel.org,
matteorizzo@...gle.com, linux-perf-users@...r.kernel.org,
santosh.shukla@....com, ananth.narayan@....com, sandipan.das@....com,
Ravi Bangoria <ravi.bangoria@....com>
Subject: Re: [PATCH v3 tip:perf/core] perf/amd/ibs: Prevent leaking sensitive
data to userspace
Hi Ingo,
>> Although IBS "swfilt" can prevent leaking samples with kernel RIP to the
>> userspace, there are few subtle cases where a 'data' address and/or a
>> 'branch target' address can fall under kernel address range although RIP
>> is from userspace. Prevent leaking kernel 'data' addresses by discarding
>> such samples when {exclude_kernel=1,swfilt=1}.
>>
>> IBS can now be invoked by unprivileged user with the introduction of
>> "swfilt". However, this creates a loophole in the interface where an
>> unprivileged user can get physical address of the userspace virtual
>> addresses through IBS register raw dump (PERF_SAMPLE_RAW). Prevent this
>> as well.
>>
>> Fixes: d29e744c7167 ("perf/x86: Relax privilege filter restriction on AMD IBS")
>> Suggested-by: Matteo Rizzo <matteorizzo@...gle.com>
>> Signed-off-by: Namhyung Kim <namhyung@...nel.org>
>> Co-developed-by: Ravi Bangoria <ravi.bangoria@....com>
>> Signed-off-by: Ravi Bangoria <ravi.bangoria@....com>
>> ---
>> v2: https://lore.kernel.org/r/20250317163755.1842589-1-namhyung@kernel.org
>>
>> arch/x86/events/amd/ibs.c | 76 ++++++++++++++++++++++++++++++++++++++-
>> 1 file changed, 75 insertions(+), 1 deletion(-)
>
> Since the initial fix is already upstream, I created a delta fix below
> for the PERF_SAMPLE_RAW fixes in -v3.
Thanks! The delta looks good.
> How well was this tested? v6.14 will be released tomorrow most likely,
> so it's a bit risky to apply such a large patch so late. Applying the
> -v1 fix was a bit risky already.
I understand. Although I've done a fair bit of testing and ran perf-
fuzzer for few hours before posting, I'm also not in favor of rushing.
I think it's safe to defer it to 6.15.
Thanks,
Ravi
Powered by blists - more mailing lists