Linux-ARM-Kernel Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: Fredrik Markstrom <fredrik.markstrom@est.tech>
To: Will Deacon <will@kernel.org>
Cc: Catalin Marinas <catalin.marinas@arm.com>,
	Shuah Khan <shuah@kernel.org>,
	Peter Zijlstra <peterz@infradead.org>,
	Ingo Molnar <mingo@redhat.com>,
	Arnaldo Carvalho de Melo <acme@kernel.org>,
	Namhyung Kim <namhyung@kernel.org>,
	Mark Rutland <mark.rutland@arm.com>,
	Alexander Shishkin <alexander.shishkin@linux.intel.com>,
	Jiri Olsa <jolsa@kernel.org>, Ian Rogers <irogers@google.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	James Clark <james.clark@linaro.org>,
	Santosh Shilimkar <santosh.shilimkar@ti.com>,
	Olof Johansson <olof@lixom.net>, Tony Lindgren <tony@atomide.com>,
	linux-arm-kernel@lists.infradead.org,
	linux-kernel@vger.kernel.org, linux-kselftest@vger.kernel.org,
	linux-perf-users@vger.kernel.org,
	Nicolas Pitre <nico@fluxnic.net>,
	Ivar Holmqvist <ivar.holmqvist@est.tech>,
	Malin Jonsson <malin.jonsson@est.tech>
Subject: Re: [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding
Date: Tue, 19 May 2026 10:25:04 +0200	[thread overview]
Message-ID: <agweYAbxRWOs41BE@elx-5cg6022w5t> (raw)
In-Reply-To: <agsq4wZMGth-T3BG@willie-the-truck>

On Mon, May 18, 2026 at 04:06:11PM +0100, Will Deacon wrote:
> On Thu, Apr 30, 2026 at 12:55:12PM +0200, Fredrik Markstrom wrote:
> > Perf callchain unwinding follows userspace frame pointers via
> > copy_from_user. A corrupted or malicious frame pointer can point
> > into device I/O memory mapped into the process (e.g. via UIO or
> > /dev/mem), causing the kernel to read from MMIO regions in PMU
> > interrupt context. Such reads can have side effects on hardware
> > (clearing status registers, advancing FIFOs, triggering DMA) and
> > on arm64 can produce a synchronous external abort that panics the
> > kernel.
> 
> Hmm, but why is unwinding special in this case? If userspace has access
> to sensitive MMIO/device mappings, it can presumably pass them to
> syscalls and trigger crashes all over the place?

You’re totally right, a broken app with access to hardware like this can
already cause chaos by passing bad pointers to syscalls etc. But the big
difference here is who is to blame when things crash.
 
If an app passes a bad pointer to a syscall, it’s self-inflicted.

Unwinding here is asynchronous and unrelated to the application.
Perf interrupts a perfectly healthy app at a random moment. If that app
is using the frame pointer as a normal register (totally legal in
optimized code), it might hold a junk value that points to MMIO memory.
 
If the kernel blindly follows that junk pointer during an unwind, perf
causes the crash. I think it's acceptable that an app (with hardware
access) causes a crash if buggy, but I don't think it's acceptable that
a profiling tool is causing a crash just by looking at it.

Fredrik


> 
> Will


  reply	other threads:[~2026-05-19  8:25 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-04-30 10:55 [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding Fredrik Markstrom
2026-04-30 10:55 ` [PATCH v2 1/3] " Fredrik Markstrom
2026-05-01  9:54   ` Fredrik Markstrom
2026-04-30 10:55 ` [PATCH v2 2/3] DO NOT MERGE: arm64: perf: Add skip_vmio parameter to control device memory callchain guard Fredrik Markstrom
2026-04-30 10:55 ` [PATCH v2 3/3] DO NOT MERGE: selftests: perf_events: Add device memory callchain unwinding test Fredrik Markstrom
2026-05-18 15:06 ` [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding Will Deacon
2026-05-19  8:25   ` Fredrik Markstrom [this message]
2026-06-11 10:32     ` Fredrik Markstrom
2026-06-19 15:31     ` Will Deacon

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=agweYAbxRWOs41BE@elx-5cg6022w5t \
    --to=fredrik.markstrom@est.tech \
    --cc=acme@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=catalin.marinas@arm.com \
    --cc=irogers@google.com \
    --cc=ivar.holmqvist@est.tech \
    --cc=james.clark@linaro.org \
    --cc=jolsa@kernel.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-kselftest@vger.kernel.org \
    --cc=linux-perf-users@vger.kernel.org \
    --cc=malin.jonsson@est.tech \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=namhyung@kernel.org \
    --cc=nico@fluxnic.net \
    --cc=olof@lixom.net \
    --cc=peterz@infradead.org \
    --cc=santosh.shilimkar@ti.com \
    --cc=shuah@kernel.org \
    --cc=tony@atomide.com \
    --cc=will@kernel.org \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox