From: Fredrik Markstrom <fredrik.markstrom@est.tech>
To: Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>, 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>
Cc: 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>,
Fredrik Markstrom <fredrik.markstrom@est.tech>,
Ivar Holmqvist <ivar.holmqvist@est.tech>,
Malin Jonsson <malin.jonsson@est.tech>
Subject: [PATCH v2 0/3] arm64: perf: Skip device memory during user callchain unwinding
Date: Thu, 30 Apr 2026 12:55:12 +0200 [thread overview]
Message-ID: <20260430-master-with-pfix-v3-v2-0-bd526ec04a75@est.tech> (raw)
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.
This series adds a guard that detects device memory before each
frame pointer read and skips the frame.
Patch 1: Lockless page table walk checking the MAIR attribute index
in the leaf PTE to identify device memory types
(MT_DEVICE_nGnRnE, MT_DEVICE_nGnRE). Follows the same
pattern as perf_get_pgtable_size() in kernel/events/core.c.
Patch 2: (DO NOT MERGE) Module parameter to disable the guard at
runtime for regression testing.
Patch 3: (DO NOT MERGE) kselftest that exercises the attack vector:
maps /dev/mem, points FP into it, and verifies the kernel
survives perf sampling.
Alternatives considered:
- VMA lookup (mmap_read_trylock + vma_lookup checking VM_IO):
requires the mmap lock on every frame.
- RCU maple tree lookup: lock-free but still a tree traversal
per frame.
- lock_vma_under_rcu: sleeping lock, unusable from IRQ context.
The page table walk requires no locks and costs only 4 pointer
dereferences per frame.
Limitations:
- The MAIR attribute check is arm64-specific. Other architectures
use different mechanisms to identify device memory and would need
their own PTE inspection logic.
- The walk only detects memory types visible in the PTE. If a page
is not present, the walk skips the frame. This has no additional
cost: copy_from_user_inatomic cannot fault in pages either, so
unwinding would stop at the same point regardless.
A QEMU-based reproducer is available at:
https://gitlab.com/frma71/qemu-kernel-tests/-/tree/vmio_perf_test?ref_type=tags
Signed-off-by: Fredrik Markstrom <fredrik.markstrom@est.tech>
---
Changes in v2:
- Added range_is_device_mem() to check both ends of the frame read
- Used module_param_unsafe with 0600 permissions
- Documented TOCTOU race in commit message
- Fixed selftest: O_CLOEXEC, mkdtemp, page size from sysconf
---
Fredrik Markstrom (3):
arm64: perf: Skip device memory during user callchain unwinding
DO NOT MERGE: arm64: perf: Add skip_vmio parameter to control device memory callchain guard
DO NOT MERGE: selftests: perf_events: Add device memory callchain unwinding test
MAINTAINERS | 1 +
arch/arm64/kernel/stacktrace.c | 116 ++++++++++++++++++
tools/testing/selftests/perf_events/Makefile | 2 +-
.../testing/selftests/perf_events/test_perf_vmio.c | 131 +++++++++++++++++++++
4 files changed, 249 insertions(+), 1 deletion(-)
---
base-commit: dca922e019dd758b4c1b4bec8f1d509efddeaab4
change-id: 20260427-master-with-pfix-v3-ae7173f538ca
Best regards,
--
Fredrik Markstrom <fredrik.markstrom@est.tech>
next reply other threads:[~2026-04-30 10:55 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-04-30 10:55 Fredrik Markstrom [this message]
2026-04-30 10:55 ` [PATCH v2 1/3] arm64: perf: Skip device memory during user callchain unwinding 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
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=20260430-master-with-pfix-v3-v2-0-bd526ec04a75@est.tech \
--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