[PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)
Jan Sebastian Götte
linux at jaseg.de
Mon Sep 28 17:17:48 UTC 2026
I'm using linux on an embedded target in a Hardware Security Module-like
application. One requirement is that I want the system to be able to
quickly erase its memory when it detects physical tampering. I'm
approaching that by using kdump to load into a small payload that
instead of dumping RAM, erases RAM frmo start to end. However, writing
all of RAM, especially on an embedded target, is rather slow. For this
reason, I propose a new crash_memaction mechanism that lets the old
kernel indicate marked memory areas to the kdump kernel at page
granularity.
I will be using this mechanism to indicate "secret" memory ranges for
early wiping by my kdump payload. After discussion with Baoquan He early
August, the patchset includes a second flag that can be used to indicate
"cache" memory that the kdump kernel may want to skip when creating the
dumpfile.
The record is a bitmap with one bit per page, allocated at boot. It
reaches the kdump kernel as a PT_NOTE named MEMACTION. Marking is a
lock-free atomic bitmap update with no allocation, so it is safe in any
context.
The feature is gated by a static key that is patched in only when the
kernel is booted with a crash_memaction= parameter indicating which
flags to pass to the kdump kernel. The parameter sets the meaning of the
bitmap bits to both kernels.
Marking Memory
==============
Theres both a kernel and a userspace interface to mark memory.
In-kernel, crash_memaction_mark() takes a virtual address range and a
type. Marking has page granularity. To support smaller objects,
patch 2 adds a "secret pool" kmem_buckets instance whose backing pages
are marked SECRET. Patches 5 to 7 move dm-crypt volume keys and IV
seeds, crypto tfm contexts, and the payloads of the user, trusted, and
encrypted key types into this pool. Keeping keys in dedicated slab
caches also provides some defence in depth against use-after-free and
out-of-bounds reads, independently of what I'm doing here with kdump.
For userspace mappings, madvise() with MADV_CRASH_SECRET or
MADV_CRASH_CACHE sets a new VMA flag, VM_CRASH_MARK. Folios mapped into
a marked VMA are registered as they arrive in rmap.
A mark lasts until the page frame is allocated again, so it is cleared
in post_alloc_hook() rather than when freed to account for leftover
data. Hugetlb folios reused from the pool bypass post_alloc_hook(), so
their marks are cleared on dequeue instead.
Overhead
========
Measured on arm64 (QRB2210, 4x Cortex-A53, 3.6G) at next-20260922, three
boots of the same tree:
k0 CONFIG_CRASH_MEMACTION=n
k1 CONFIG_CRASH_MEMACTION=y, no crash_memaction=
k2 CONFIG_CRASH_MEMACTION=y, crash_memaction=secret
k1 and k2 are the same kernel image. The workload rebuilds mm/ of a
kernel tree a few times with make -j4.
k0 157.05 s median (n=8, range 156.51-157.77)
k1 158.23 s median (n=8, range 157.96-159.69)
k2 157.42 s median (n=8, range 156.97-163.24)
Against k0 that is +0.75% for k1 and +0.24% for k2, both within
measurement noise.
Out of scope here
=================
This series only records the page types in the note. The secret type is
wired up with some kernel users related to disk encryption. The cache
type is not wired up with any kernel users (but can be used from
userspace).
The bitmap is sized from the memblock memory map at boot and is never
resized. Memory added by hotplug is therefore not covered by a bitmap
and cannot be marked. I'm focused on embedded targets that don't support
hotplug anyway.
Signed-off-by: Jan Sebastian Götte <linux at jaseg.de>
---
Changes in v3:
- Use page bitmap instead of range-based registry
- Move smaller allocations into secret_pool buckets
- Link to v3: https://patch.msgid.link/20260811-crash-zeroize-rework-v2-0-9561d13c2340@jaseg.de
To: Jonathan Corbet <corbet at lwn.net>
To: Shuah Khan <skhan at linuxfoundation.org>
To: Randy Dunlap <rdunlap at infradead.org>
To: Rob Herring <robh at kernel.org>
To: Saravana Kannan <saravanak at kernel.org>
To: Andrew Morton <akpm at linux-foundation.org>
To: Baoquan He <baoquan.he at linux.dev>
To: Mike Rapoport <rppt at kernel.org>
To: Pasha Tatashin <pasha.tatashin at soleen.com>
To: Pratyush Yadav <pratyush at kernel.org>
To: Dave Young <ruirui.yang at linux.dev>
To: Greg Kroah-Hartman <gregkh at linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael at kernel.org>
To: Danilo Krummrich <dakr at kernel.org>
To: Muchun Song <muchun.song at linux.dev>
To: Oscar Salvador <osalvador at suse.de>
To: David Hildenbrand <david at kernel.org>
To: Vlastimil Babka <vbabka at kernel.org>
To: Suren Baghdasaryan <surenb at google.com>
To: Michal Hocko <mhocko at suse.com>
To: Brendan Jackman <brendan.jackman at linux.dev>
To: Johannes Weiner <hannes at cmpxchg.org>
To: Zi Yan <ziy at nvidia.com>
To: Catalin Marinas <catalin.marinas at arm.com>
To: Will Deacon <will at kernel.org>
To: Mark Rutland <mark.rutland at arm.com>
To: Alasdair Kergon <agk at redhat.com>
To: Mike Snitzer <snitzer at kernel.org>
To: Mikulas Patocka <mpatocka at redhat.com>
To: Benjamin Marzinski <bmarzins at redhat.com>
To: Herbert Xu <herbert at gondor.apana.org.au>
To: "David S. Miller" <davem at davemloft.net>
To: Mimi Zohar <zohar at linux.ibm.com>
To: David Howells <dhowells at redhat.com>
To: Jarkko Sakkinen <jarkko at kernel.org>
To: Paul Moore <paul at paul-moore.com>
To: James Morris <jmorris at namei.org>
To: "Serge E. Hallyn" <serge at hallyn.com>
To: James Bottomley <James.Bottomley at HansenPartnership.com>
To: "Liam R. Howlett" <liam at infradead.org>
To: Lorenzo Stoakes <ljs at kernel.org>
To: Jann Horn <jannh at google.com>
To: Pedro Falcato <pfalcato at suse.de>
To: Rik van Riel <riel at surriel.com>
To: Harry Yoo <harry at kernel.org>
To: Lance Yang <lance.yang at linux.dev>
To: Baolin Wang <baolin.wang at linux.alibaba.com>
To: Nico Pache <nico.pache at linux.dev>
To: Ryan Roberts <ryan.roberts at arm.com>
To: Dev Jain <dev.jain at arm.com>
To: Barry Song <baohua at kernel.org>
To: Usama Arif <usama.arif at linux.dev>
To: Kiryl Shutsemau <kas at kernel.org>
To: Matthew Brost <matthew.brost at intel.com>
To: Joshua Hahn <joshua.hahnjy at gmail.com>
To: Byungchul Park <byungchul at sk.com>
To: Gregory Price <gourry at gourry.net>
To: Ying Huang <ying.huang at linux.alibaba.com>
To: Alistair Popple <apopple at nvidia.com>
To: Peter Xu <peterx at redhat.com>
To: Arnd Bergmann <arnd at arndb.de>
Cc: linux-doc at vger.kernel.org
Cc: linux-kernel at vger.kernel.org
Cc: devicetree at vger.kernel.org
Cc: kexec at lists.infradead.org
Cc: driver-core at lists.linux.dev
Cc: linux-mm at kvack.org
Cc: linux-arm-kernel at lists.infradead.org
Cc: dm-devel at lists.linux.dev
Cc: linux-crypto at vger.kernel.org
Cc: linux-integrity at vger.kernel.org
Cc: keyrings at vger.kernel.org
Cc: linux-security-module at vger.kernel.org
Cc: linux-fsdevel at vger.kernel.org
Cc: linux-arch at vger.kernel.org
---
Jan Sebastian Götte (12):
kexec: Add a crash memaction registry
lib, kexec: Add a secret pool for key material
mm: Wire up the crash memaction registry
arm64: Enable the crash memaction registry
dm crypt: Allocate key material from the secret pool
crypto: api - Allocate tfms from the secret pool
security/keys: Allocate key payloads from the secret pool
mm: Add VM_CRASH_MARK
mm/rmap: Mark folios mapped into crash_memaction-marked VMAs
mm/madvise: Add MADV_CRASH_SECRET, MADV_CRASH_CACHE and MADV_CRASH_RESET
Documentation/mm: Document the crash memaction registry
kexec: Expose the crash memaction bitmap in debugfs
Documentation/admin-guide/kernel-parameters.txt | 9 +
Documentation/mm/crash_memaction.rst | 68 ++++
Documentation/mm/index.rst | 1 +
MAINTAINERS | 4 +
arch/arm64/Kconfig | 3 +
crypto/api.c | 9 +-
drivers/md/dm-crypt.c | 19 +-
drivers/of/kexec.c | 7 +
fs/proc/task_mmu.c | 3 +
include/linux/crash_memaction.h | 86 +++++
include/linux/kexec.h | 6 +
include/linux/mm.h | 9 +
include/linux/rmap.h | 5 +-
include/linux/secret_pool.h | 47 +++
include/uapi/asm-generic/mman-common.h | 4 +
kernel/Kconfig.kexec | 39 ++
kernel/crash_core.c | 475 ++++++++++++++++++++++++
kernel/kexec_core.c | 4 +
kernel/kexec_file.c | 10 +
kernel/ksysfs.c | 15 +
lib/Makefile | 1 +
lib/secret_pool.c | 27 ++
mm/huge_memory.c | 2 +
mm/hugetlb.c | 10 +-
mm/madvise.c | 132 +++++++
mm/migrate.c | 2 +-
mm/mm_init.c | 3 +
mm/page_alloc.c | 6 +
mm/rmap.c | 8 +
mm/userfaultfd.c | 1 +
security/keys/encrypted-keys/encrypted.c | 5 +-
security/keys/trusted-keys/trusted_core.c | 3 +-
security/keys/user_defined.c | 3 +-
33 files changed, 1006 insertions(+), 20 deletions(-)
---
base-commit: a8c591ed6b672915e0be57843f943a2a723aff40
change-id: 20260925-crash-memaction-upstream-20260921-6e3cfac5a389
Best regards,
--
Jan Sebastian Götte <linux at jaseg.de>
More information about the Linux-security-module-archive
mailing list