All of lore.kernel.org
 help / color / mirror / Atom feed
From: Namhyung Kim <namhyung@kernel.org>
To: Ravi Bangoria <ravi.bangoria@amd.com>
Cc: Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@kernel.org>,
	Kan Liang <kan.liang@linux.intel.com>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	LKML <linux-kernel@vger.kernel.org>,
	Matteo Rizzo <matteorizzo@google.com>
Subject: Re: [PATCH v2] perf/x86: Check data address for IBS software filter
Date: Wed, 19 Mar 2025 13:30:04 -0700	[thread overview]
Message-ID: <Z9spTE_M47M4qpCR@google.com> (raw)
In-Reply-To: <d1dec8b8-10c8-4da0-920a-d1f744543253@amd.com>

On Wed, Mar 19, 2025 at 04:24:12PM +0530, Ravi Bangoria wrote:
> Hi Namhyung,
> 
> >>> IBS software filter was to filter kernel samples for regular users in
> >>> PMI handler.  It checks the instruction address in the IBS register to
> >>> determine if it was in the kernel more or not.
> >>>
> >>> But it turns out that it's possible to report a kernel data address even
> >>> if the instruction address belongs to the user space.  Matteo Rizzo
> >>> found that when an instruction raises an exception, IBS can report some
> >>> kernel data address like IDT while holding the faulting instruction's
> >>> RIP.  To prevent an information leak, it should double check if the data
> >>> address in PERF_SAMPLE_DATA is in the kernel space as well.
> >>
> >> PERF_SAMPLE_RAW can also leak kernel data address. How about:
> > 
> > Thanks for your review.
> > 
> > I think RAW is different as it requires perf_event_paranoid == -1.
> 
> IBS allows PERF_SAMPLE_RAW irrespective of perf_event_paranoid. e.g.:
> 
>   $ cat /proc/sys/kernel/perf_event_paranoid
>   2
> 
>   $ ./perf record -e ibs_op/swfilt=1/u --raw-samples -- make
>   [ perf record: Woken up 1 times to write data ]
>   [ perf record: Captured and wrote 1.371 MB perf.data (3957 samples) ]
> 
>   $ ./perf script -D | egrep -A2 "LdOp 1.*DcLinAddrValid 1" | egrep "IbsDCLinAd:\s*f"
>   IbsDCLinAd:     fffffe00000000e8

Oh, I thought it was enforced in the core layer but it turns out that
it's checked only by tracepoint events.

> 
> We have two options:
> 1) Restrict IBS + PERF_SAMPLE_RAW to privilege users.
> 2) Remove all sensitive information from raw register dump before
>    passing it to userspace. (Kernel data addresses and all physical
>    addresses are the only sensitive info I suppose?).
> 
> 2 is better IMO since it will allow unprivileged user to use IBS
> with full potential. wdyt?

I'm slightly inclined to #1 for simplicity and safety, but #2 is fine to
me as well.

Thanks,
Namhyung


  reply	other threads:[~2025-03-19 20:30 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-03-17 16:37 [PATCH v2] perf/x86: Check data address for IBS software filter Namhyung Kim
2025-03-17 22:51 ` [tip: perf/urgent] " tip-bot2 for Namhyung Kim
2025-03-18 10:32 ` [PATCH v2] " Ravi Bangoria
2025-03-18 18:09   ` Namhyung Kim
2025-03-19 10:54     ` Ravi Bangoria
2025-03-19 20:30       ` Namhyung Kim [this message]
2025-03-19 22:18         ` Ingo Molnar
2025-03-21 16:19           ` Ravi Bangoria

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=Z9spTE_M47M4qpCR@google.com \
    --to=namhyung@kernel.org \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=kan.liang@linux.intel.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=matteorizzo@google.com \
    --cc=mingo@kernel.org \
    --cc=peterz@infradead.org \
    --cc=ravi.bangoria@amd.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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.