[PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)

[PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)

[Jan Sebastian Götte]

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@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@lwn.net>
To: Shuah Khan <skhan@linuxfoundation.org>
To: Randy Dunlap <rdunlap@infradead.org>
To: Rob Herring <robh@kernel.org>
To: Saravana Kannan <saravanak@kernel.org>
To: Andrew Morton <akpm@linux-foundation.org>
To: Baoquan He <baoquan.he@linux.dev>
To: Mike Rapoport <rppt@kernel.org>
To: Pasha Tatashin <pasha.tatashin@soleen.com>
To: Pratyush Yadav <pratyush@kernel.org>
To: Dave Young <ruirui.yang@linux.dev>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
To: "Rafael J. Wysocki" <rafael@kernel.org>
To: Danilo Krummrich <dakr@kernel.org>
To: Muchun Song <muchun.song@linux.dev>
To: Oscar Salvador <osalvador@suse.de>
To: David Hildenbrand <david@kernel.org>
To: Vlastimil Babka <vbabka@kernel.org>
To: Suren Baghdasaryan <surenb@google.com>
To: Michal Hocko <mhocko@suse.com>
To: Brendan Jackman <brendan.jackman@linux.dev>
To: Johannes Weiner <hannes@cmpxchg.org>
To: Zi Yan <ziy@nvidia.com>
To: Catalin Marinas <catalin.marinas@arm.com>
To: Will Deacon <will@kernel.org>
To: Mark Rutland <mark.rutland@arm.com>
To: Alasdair Kergon <agk@redhat.com>
To: Mike Snitzer <snitzer@kernel.org>
To: Mikulas Patocka <mpatocka@redhat.com>
To: Benjamin Marzinski <bmarzins@redhat.com>
To: Herbert Xu <herbert@gondor.apana.org.au>
To: "David S. Miller" <davem@davemloft.net>
To: Mimi Zohar <zohar@linux.ibm.com>
To: David Howells <dhowells@redhat.com>
To: Jarkko Sakkinen <jarkko@kernel.org>
To: Paul Moore <paul@paul-moore.com>
To: James Morris <jmorris@namei.org>
To: "Serge E. Hallyn" <serge@hallyn.com>
To: James Bottomley <James.Bottomley@HansenPartnership.com>
To: "Liam R. Howlett" <liam@infradead.org>
To: Lorenzo Stoakes <ljs@kernel.org>
To: Jann Horn <jannh@google.com>
To: Pedro Falcato <pfalcato@suse.de>
To: Rik van Riel <riel@surriel.com>
To: Harry Yoo <harry@kernel.org>
To: Lance Yang <lance.yang@linux.dev>
To: Baolin Wang <baolin.wang@linux.alibaba.com>
To: Nico Pache <nico.pache@linux.dev>
To: Ryan Roberts <ryan.roberts@arm.com>
To: Dev Jain <dev.jain@arm.com>
To: Barry Song <baohua@kernel.org>
To: Usama Arif <usama.arif@linux.dev>
To: Kiryl Shutsemau <kas@kernel.org>
To: Matthew Brost <matthew.brost@intel.com>
To: Joshua Hahn <joshua.hahnjy@gmail.com>
To: Byungchul Park <byungchul@sk.com>
To: Gregory Price <gourry@gourry.net>
To: Ying Huang <ying.huang@linux.alibaba.com>
To: Alistair Popple <apopple@nvidia.com>
To: Peter Xu <peterx@redhat.com>
To: Arnd Bergmann <arnd@arndb.de>
Cc: linux-doc@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: devicetree@vger.kernel.org
Cc: kexec@lists.infradead.org
Cc: driver-core@lists.linux.dev
Cc: linux-mm@kvack.org
Cc: linux-arm-kernel@lists.infradead.org
Cc: dm-devel@lists.linux.dev
Cc: linux-crypto@vger.kernel.org
Cc: linux-integrity@vger.kernel.org
Cc: keyrings@vger.kernel.org
Cc: linux-security-module@vger.kernel.org
Cc: linux-fsdevel@vger.kernel.org
Cc: linux-arch@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@jaseg.de>

[PATCH v3 01/12] kexec: Add a crash memaction registry

[Jan Sebastian Götte]

Add a registry identifying page use to a kdump kernel. Intended uses are
wiping of crypto keys on crash, or omitting pages holding e.g. crypto
keys or unimportant caches from crash dumps.

The registry is a bitmap with one bit for each physical page. The
meaning of the bits is set by the crash_memaction= cmdline param. When
not present, no bitmap is allocated. Marking is a lock-free bitmap
update with no allocation, so it is safe from any context.

The bitmap and its metadata is handed over to the kdump kernel through
elfcorehdr.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 Documentation/admin-guide/kernel-parameters.txt |   9 +
 MAINTAINERS                                     |   1 +
 drivers/of/kexec.c                              |   7 +
 include/linux/crash_memaction.h                 |  71 ++++
 include/linux/kexec.h                           |   6 +
 kernel/Kconfig.kexec                            |  21 ++
 kernel/crash_core.c                             | 416 ++++++++++++++++++++++++
 kernel/kexec_core.c                             |   4 +
 kernel/kexec_file.c                             |  10 +
 kernel/ksysfs.c                                 |  15 +
 10 files changed, 560 insertions(+)

diff --git a/Documentation/admin-guide/kernel-parameters.txt b/Documentation/admin-guide/kernel-parameters.txt
index 2041dd9a8f18..26a78335c156 100644
--- a/Documentation/admin-guide/kernel-parameters.txt
+++ b/Documentation/admin-guide/kernel-parameters.txt
@@ -1040,6 +1040,15 @@ Kernel parameters
 			Default is enabled if CONFIG_HOTPLUG_PARALLEL=y. Otherwise
 			the parameter has no effect.
 
+	crash_memaction={secret|cache}[,...]
+			[KNL,EARLY] When CONFIG_CRASH_MEMACTION is set, this
+			parameter instructs the kernel to hand an eventual
+			kdump kernel a bitmap of pages annotated with the
+			given types. Annotations are made with madvise(2).
+			Kernel crypto keys are annotated secret. What the
+			kdump kernel does with this is up to it. Default is
+			nothing is tracked and no bitmap is created.
+
 	crash_kexec_post_notifiers
 			Only jump to kdump kernel after running the panic
 			notifiers and dumping kmsg. This option increases
diff --git a/MAINTAINERS b/MAINTAINERS
index dccddc99ac9a..c6350fd34f4c 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14259,6 +14259,7 @@ F:	Documentation/admin-guide/kdump/
 F:	fs/proc/vmcore.c
 F:	include/linux/crash_core.h
 F:	include/linux/crash_dump.h
+F:	include/linux/crash_memaction.h
 F:	include/uapi/linux/vmcore.h
 F:	kernel/crash_*.c
 
diff --git a/drivers/of/kexec.c b/drivers/of/kexec.c
index 029903b986cb..a4d9eca9debe 100644
--- a/drivers/of/kexec.c
+++ b/drivers/of/kexec.c
@@ -442,6 +442,13 @@ void *of_kexec_alloc_and_setup_fdt(const struct kimage *image,
 				goto out;
 		}
 
+		if (image->memaction_addr != 0) {
+			ret = fdt_add_mem_rsv(fdt, image->memaction_addr,
+					      image->memaction_sz);
+			if (ret)
+				goto out;
+		}
+
 #ifdef CONFIG_CRASH_DUMP
 		/* add linux,usable-memory-range */
 		ret = fdt_appendprop_addrrange(fdt, 0, chosen_node,
diff --git a/include/linux/crash_memaction.h b/include/linux/crash_memaction.h
new file mode 100644
index 000000000000..5f3e114c60ad
--- /dev/null
+++ b/include/linux/crash_memaction.h
@@ -0,0 +1,71 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef LINUX_CRASH_MEMACTION_H
+#define LINUX_CRASH_MEMACTION_H
+
+#include <linux/init.h>
+#include <linux/jump_label.h>
+#include <linux/types.h>
+
+struct kimage;
+
+enum crash_memaction_types {
+	CRASH_MEMACTION_CACHE = 0x1000,
+	CRASH_MEMACTION_SECRET = 0x2000,
+};
+
+#define CRASH_MEMACTION_NOTE_NAME	"MEMACTION"
+
+/*
+ * Bit n of the bitmap at @bitmap_paddr stands for the page frame at
+ * @start_pfn + n.
+ */
+struct crash_memaction_region_note {
+	u64 start_pfn;
+	u64 nr_pages;
+	u64 bitmap_paddr;
+};
+
+/* Wire format between the two kernels */
+struct crash_memaction_note {
+	u32 types; /* CRASH_MEMACTION_* types that set bitmap bits stand for */
+	u32 page_shift;
+	u32 nr_regions;
+	u32 _pad;
+	struct crash_memaction_region_note regions[];
+};
+
+#ifdef CONFIG_CRASH_MEMACTION
+void __init crash_memaction_init(void);
+
+DECLARE_STATIC_KEY_FALSE(crash_memaction_active);
+
+/* Safe from any context. */
+void __crash_memaction_mark_pfns(unsigned long pfn, unsigned long nr_pages);
+void __crash_memaction_unmark_pfns(unsigned long pfn, unsigned long nr_pages);
+
+static inline void crash_memaction_unmark_pfns(unsigned long pfn,
+		unsigned long nr_pages)
+{
+	if (static_branch_unlikely(&crash_memaction_active))
+		__crash_memaction_unmark_pfns(pfn, nr_pages);
+}
+
+void crash_memaction_mark(void *addr, size_t size, int types);
+void crash_memaction_unmark(void *addr, size_t size);
+
+int crash_memaction_types(void);
+ssize_t crash_memaction_types_str(char *buf);
+
+int crash_load_memaction(struct kimage *image);
+void crash_memaction_unload(struct kimage *image);
+#else
+static inline void crash_memaction_init(void) { }
+static inline void crash_memaction_unmark_pfns(unsigned long pfn,
+		unsigned long nr_pages) { }
+static inline void crash_memaction_mark(void *addr, size_t size, int types) { }
+static inline void crash_memaction_unmark(void *addr, size_t size) { }
+static inline int crash_memaction_types(void) { return 0; }
+static inline int crash_load_memaction(struct kimage *image) { return 0; }
+static inline void crash_memaction_unload(struct kimage *image) { }
+#endif /* CONFIG_CRASH_MEMACTION */
+#endif /* LINUX_CRASH_MEMACTION_H */
diff --git a/include/linux/kexec.h b/include/linux/kexec.h
index e5f1cfc11fef..f4a2450be879 100644
--- a/include/linux/kexec.h
+++ b/include/linux/kexec.h
@@ -415,6 +415,12 @@ struct kimage {
 	/* dm crypt keys buffer */
 	unsigned long dm_crypt_keys_addr;
 	unsigned long dm_crypt_keys_sz;
+
+	/* crash memaction descriptor buffer */
+	void *memaction_note_va;
+	unsigned long memaction_addr;
+	unsigned long memaction_sz;
+	int memaction_index;
 };
 
 /* kexec interface functions */
diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index a97ed9605602..f7326fa6476b 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -179,4 +179,25 @@ config CRASH_MAX_MEMORY_RANGES
 	  the computation behind the value provided through the
 	  /sys/kernel/crash_elfcorehdr_size attribute.
 
+config ARCH_SUPPORTS_CRASH_MEMACTION
+	bool
+
+config CRASH_MEMACTION
+	bool "Register kdump actions for certain memory ranges"
+	depends on CRASH_DUMP
+	depends on KEXEC_FILE
+	depends on ARCH_SUPPORTS_CRASH_MEMACTION
+	help
+	  Track pages that may require special handling by the kdump kernel:
+	  pages holding secrets such as crypto keys, which it can wipe before
+	  anything reads the dump, and pages not worth dumping at all. This
+	  kernel only records which pages are which; what happens to them is
+	  the kdump kernel's decision.
+
+	  Nothing is tracked and no memory is spent unless the kernel is booted
+	  with the crash_memaction= parameter, which also says which types the
+	  bits stand for. The bitmap then costs about 32 KiB per GiB of memory.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index d0bd2d0cf899..6bb2f5645ca6 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -18,11 +18,23 @@
 #include <linux/memblock.h>
 #include <linux/kmemleak.h>
 #include <linux/crash_core.h>
+#include <linux/crash_memaction.h>
 #include <linux/reboot.h>
 #include <linux/btf.h>
 #include <linux/objtool.h>
 #include <linux/delay.h>
 #include <linux/panic.h>
+#include <linux/timekeeping.h>
+#include <linux/atomic.h>
+#include <linux/bitmap.h>
+#include <linux/bitops.h>
+#include <linux/jump_label.h>
+#include <linux/overflow.h>
+#include <linux/pfn.h>
+#include <linux/slab.h>
+#include <linux/string.h>
+#include <linux/sysfs.h>
+#include <linux/vmcore_info.h>
 
 #include <asm/page.h>
 #include <asm/sections.h>
@@ -33,6 +45,406 @@
 /* Per cpu memory for storing cpu states in case of system crash. */
 note_buf_t __percpu *crash_notes;
 
+#ifdef CONFIG_CRASH_MEMACTION
+
+#define CRASH_MEMACTION_NOTE_NAME_BYTES \
+	ALIGN(sizeof(CRASH_MEMACTION_NOTE_NAME), 4)
+
+/* Bitmap a hole may waste before it gets a region of its own. */
+#define CRASH_MEMACTION_MAX_HOLE_BYTES	SZ_128K
+
+DEFINE_STATIC_KEY_FALSE(crash_memaction_active);
+EXPORT_SYMBOL_GPL(crash_memaction_active);
+
+struct crash_memaction_region {
+	unsigned long start_pfn;
+	unsigned long nr_pages;
+	unsigned long *bits;
+};
+
+static struct crash_memaction_region *crash_memaction_regions __ro_after_init;
+static unsigned int crash_memaction_nr_regions __ro_after_init;
+static size_t crash_memaction_note_bytes __ro_after_init;
+
+static struct crash_memaction_note *crash_memaction_desc __ro_after_init;
+static size_t crash_memaction_desc_bytes __ro_after_init;
+
+static phys_addr_t crash_memaction_note_paddr;
+
+static int crash_memaction_type_mask __ro_after_init;
+
+int crash_memaction_types(void)
+{
+	return crash_memaction_type_mask;
+}
+
+static int __init crash_memaction_param(char *str)
+{
+	char *tok;
+
+	while ((tok = strsep(&str, ",")) != NULL) {
+		if (!strcmp(tok, "secret"))
+			crash_memaction_type_mask |= CRASH_MEMACTION_SECRET;
+		else if (!strcmp(tok, "cache"))
+			crash_memaction_type_mask |= CRASH_MEMACTION_CACHE;
+		else if (*tok)
+			pr_warn("memaction: ignoring unknown type \"%s\"\n",
+				tok);
+	}
+	return 0;
+}
+early_param("crash_memaction", crash_memaction_param);
+
+ssize_t crash_memaction_types_str(char *buf)
+{
+	int mask = crash_memaction_type_mask;
+	int len = 0;
+
+	if (mask & CRASH_MEMACTION_SECRET)
+		len += sysfs_emit_at(buf, len, "secret");
+	if (mask & CRASH_MEMACTION_CACHE)
+		len += sysfs_emit_at(buf, len, "%scache", len ? "," : "");
+
+	return len + sysfs_emit_at(buf, len, "\n");
+}
+
+void __init crash_memaction_init(void)
+{
+	struct crash_memaction_region *regions;
+	struct crash_memaction_note *desc;
+	unsigned long total_bytes = 0;
+	unsigned long start, end, prev_end;
+	unsigned int nr = 0, i;
+	size_t desc_bytes;
+	void *bits;
+	int idx;
+
+	if (!crash_memaction_type_mask)
+		return;
+
+	regions = memblock_alloc(memblock.memory.cnt * sizeof(*regions),
+				 SMP_CACHE_BYTES);
+	if (!regions)
+		goto nomem;
+
+	for_each_mem_pfn_range(idx, NUMA_NO_NODE, &start, &end, NULL) {
+		if (nr && bitmap_size(start - prev_end) <=
+				CRASH_MEMACTION_MAX_HOLE_BYTES) {
+			regions[nr - 1].nr_pages = max(
+					end - regions[nr - 1].start_pfn,
+					regions[nr - 1].nr_pages);
+		} else {
+			regions[nr].start_pfn = start;
+			regions[nr].nr_pages = end - start;
+			nr++;
+		}
+		prev_end = end;
+	}
+
+	for (i = 0; i < nr; i++)
+		total_bytes += bitmap_size(regions[i].nr_pages);
+
+	bits = memblock_alloc(total_bytes, PAGE_SIZE);
+	if (!bits)
+		goto nomem;
+
+	for (i = 0; i < nr; i++) {
+		regions[i].bits = bits;
+		bits += bitmap_size(regions[i].nr_pages);
+	}
+
+	desc_bytes = struct_size_t(struct crash_memaction_note, regions, nr);
+	desc = memblock_alloc(desc_bytes, sizeof(u64));
+	if (!desc)
+		goto nomem;
+
+	desc->types = crash_memaction_type_mask;
+	desc->page_shift = PAGE_SHIFT;
+	desc->nr_regions = nr;
+	for (i = 0; i < nr; i++) {
+		desc->regions[i].start_pfn = regions[i].start_pfn;
+		desc->regions[i].nr_pages = regions[i].nr_pages;
+		desc->regions[i].bitmap_paddr = __pa(regions[i].bits);
+	}
+
+	crash_memaction_regions = regions;
+	crash_memaction_nr_regions = nr;
+	crash_memaction_desc = desc;
+	crash_memaction_desc_bytes = desc_bytes;
+	crash_memaction_note_bytes =
+		PAGE_ALIGN(2 * sizeof(struct elf_note) +
+			   CRASH_MEMACTION_NOTE_NAME_BYTES +
+			   ALIGN(desc_bytes, 4));
+
+	static_branch_enable(&crash_memaction_active);
+
+	pr_info("crash_memaction: types 0x%x, %u memory region(s), %lu KiB of bitmap\n",
+		crash_memaction_type_mask, nr, total_bytes >> 10);
+	return;
+
+nomem:
+	crash_memaction_type_mask = 0;
+	pr_err("crash_memaction: cannot allocate page bitmaps, disabled\n");
+}
+
+/*
+ * The clear reads before it writes: it runs on every frame the page allocator
+ * hands out and almost never has anything to do, so this keeps an allocation
+ * from dirtying a cache line for frames it has nothing to do with.
+ */
+static __always_inline void crash_memaction_word(atomic_long_t *p, unsigned long mask, bool set)
+{
+	unsigned long val = atomic_long_read(p);
+
+	if (set) {
+		if ((val & mask) != mask)
+			atomic_long_or(mask, p);
+	} else if (val & mask) {
+		atomic_long_andnot(mask, p);
+	}
+}
+
+/*
+ * __bitmap_set() and __bitmap_clear() merged, with the store made atomic: the
+ * partial words at either end can be shared with an unrelated folio, and
+ * marking runs from rmap with no lock. Counts are unsigned long rather than
+ * the header's unsigned int, which a bit per page frame outgrows.
+ */
+static void __crash_memaction_bits(unsigned long *map, unsigned long start,
+		unsigned long nr, bool set)
+{
+	atomic_long_t *p = (atomic_long_t *)(map + BIT_WORD(start));
+	const unsigned long size = start + nr;
+	unsigned long bits = BITS_PER_LONG - (start % BITS_PER_LONG);
+	unsigned long mask = BITMAP_FIRST_WORD_MASK(start);
+
+	/* Unsigned, so this is __bitmap_set()'s "nr - bits >= 0". */
+	while (nr >= bits) {
+		crash_memaction_word(p, mask, set);
+		nr -= bits;
+		bits = BITS_PER_LONG;
+		mask = ~0UL;
+		p++;
+	}
+
+	if (nr) {
+		mask &= BITMAP_LAST_WORD_MASK(size);
+		crash_memaction_word(p, mask, set);
+	}
+}
+
+static __always_inline void crash_memaction_bits(unsigned long *map,
+		unsigned long start, unsigned long nr, bool set)
+{
+	if (nr == 1) {
+		if (set) {
+			if (!test_bit(start, map))
+				set_bit(start, map);
+		} else if (test_bit(start, map)) {
+			clear_bit(start, map);
+		}
+		return;
+	}
+
+	__crash_memaction_bits(map, start, nr, set);
+}
+
+static void crash_memaction_update(unsigned long start_pfn,
+		unsigned long nr_pages, bool set)
+{
+	unsigned long end_pfn = start_pfn + nr_pages;
+	unsigned int i;
+
+	for (i = 0; i < crash_memaction_nr_regions; i++) {
+		struct crash_memaction_region *reg = &crash_memaction_regions[i];
+		unsigned long from = max(start_pfn, reg->start_pfn);
+		unsigned long to = min(end_pfn, reg->start_pfn + reg->nr_pages);
+
+		if (reg->start_pfn >= end_pfn)
+			break;
+		if (from < to)
+			crash_memaction_bits(reg->bits, from - reg->start_pfn,
+					     to - from, set);
+	}
+}
+
+void __crash_memaction_mark_pfns(unsigned long pfn, unsigned long nr_pages)
+{
+	crash_memaction_update(pfn, nr_pages, true);
+}
+EXPORT_SYMBOL_GPL(__crash_memaction_mark_pfns);
+
+void __crash_memaction_unmark_pfns(unsigned long pfn, unsigned long nr_pages)
+{
+	crash_memaction_update(pfn, nr_pages, false);
+}
+EXPORT_SYMBOL_GPL(__crash_memaction_unmark_pfns);
+
+static void crash_memaction_va(void *addr, size_t size, bool set)
+{
+	unsigned long start = ALIGN_DOWN((unsigned long)addr, PAGE_SIZE);
+	unsigned long end = ALIGN((unsigned long)addr + size, PAGE_SIZE);
+	unsigned long va;
+
+	if (!addr || !size)
+		return;
+
+	if (virt_addr_valid(addr)) {
+		if (!virt_addr_valid((void *)(end - 1))) {
+			pr_warn("memaction: invalid range 0x%p+%zx\n",
+				addr, size);
+			return;
+		}
+
+		/* The linear map is physically contiguous. */
+		crash_memaction_update(PHYS_PFN(virt_to_phys((void *)start)),
+				       (end - start) >> PAGE_SHIFT, set);
+		return;
+	}
+
+	if (!is_vmalloc_addr(addr)) {
+		pr_warn("memaction: invalid range 0x%p+%zx: neither linear nor vmalloc\n",
+			addr, size);
+		return;
+	}
+
+	for (va = start; va < end; va += PAGE_SIZE) {
+		struct page *page = vmalloc_to_page((void *)va);
+
+		if (!page) {
+			pr_warn("memaction: unmapped page 0x%lx inside range 0x%p+%zx\n",
+				va, addr, size);
+			return;
+		}
+
+		crash_memaction_update(page_to_pfn(page), 1, set);
+	}
+}
+
+void crash_memaction_mark(void *addr, size_t size, int types)
+{
+	if (!static_branch_unlikely(&crash_memaction_active))
+		return;
+	if (!(types & crash_memaction_type_mask))
+		return;
+
+	crash_memaction_va(addr, size, true);
+}
+EXPORT_SYMBOL_GPL(crash_memaction_mark);
+
+void crash_memaction_unmark(void *addr, size_t size)
+{
+	if (!static_branch_unlikely(&crash_memaction_active))
+		return;
+
+	crash_memaction_va(addr, size, false);
+}
+EXPORT_SYMBOL_GPL(crash_memaction_unmark);
+
+int crash_load_memaction(struct kimage *image)
+{
+	unsigned long nr_pages, i;
+	struct page **pages;
+	int ret;
+	struct kexec_buf kbuf = {
+		.image = image,
+		.buffer = NULL,
+		.bufsz = 0,
+		.mem = KEXEC_BUF_MEM_UNKNOWN,
+		.memsz = crash_memaction_note_bytes,
+		.buf_align = PAGE_SIZE,
+		.buf_min = 0,
+		.buf_max = ULONG_MAX,
+		.top_down = true,
+		.random = true,
+	};
+
+	if (!crash_memaction_nr_regions)
+		return 0;
+
+	ret = kexec_add_buffer(&kbuf);
+	if (ret)
+		return ret;
+
+	nr_pages = crash_memaction_note_bytes / PAGE_SIZE;
+	pages = kmalloc_array(nr_pages, sizeof(*pages), GFP_KERNEL);
+	if (!pages)
+		return -ENOMEM;
+
+	for (i = 0; i < nr_pages; i++)
+		pages[i] = pfn_to_page((kbuf.mem >> PAGE_SHIFT) + i);
+
+	image->memaction_note_va = vmap(pages, nr_pages, VM_MAP, PAGE_KERNEL);
+	kfree(pages);
+	if (!image->memaction_note_va)
+		return -ENOMEM;
+
+	image->memaction_addr = kbuf.mem;
+	image->memaction_sz = kbuf.memsz;
+	image->memaction_index = image->nr_segments - 1;
+	crash_memaction_note_paddr = kbuf.mem;
+
+	return 0;
+}
+
+void crash_memaction_unload(struct kimage *image)
+{
+	if (!image->memaction_note_va)
+		return;
+
+	vunmap(image->memaction_note_va);
+	image->memaction_note_va = NULL;
+	image->memaction_addr = 0;
+	image->memaction_sz = 0;
+	image->memaction_index = -1;
+	crash_memaction_note_paddr = 0;
+}
+
+static void crash_memaction_save(struct kimage *image)
+{
+	if (!image || !image->memaction_note_va)
+		return;
+
+	final_note(append_elf_note(image->memaction_note_va,
+				   CRASH_MEMACTION_NOTE_NAME, 0,
+				   crash_memaction_desc,
+				   crash_memaction_desc_bytes));
+}
+
+static unsigned long crash_memaction_nr_phdr(void)
+{
+	return crash_memaction_note_paddr ? 1 : 0;
+}
+
+static Elf64_Phdr *crash_memaction_emit_phdr(Elf64_Ehdr *ehdr,
+		Elf64_Phdr *phdr)
+{
+	if (!crash_memaction_note_paddr)
+		return phdr;
+
+	phdr->p_type = PT_NOTE;
+	phdr->p_offset = phdr->p_paddr = crash_memaction_note_paddr;
+	phdr->p_filesz = phdr->p_memsz = crash_memaction_note_bytes;
+	(ehdr->e_phnum)++;
+
+	return phdr + 1;
+}
+
+#else
+static inline void crash_memaction_save(struct kimage *image) { }
+
+static inline unsigned long crash_memaction_nr_phdr(void)
+{
+	return 0;
+}
+
+static inline Elf64_Phdr *crash_memaction_emit_phdr(Elf64_Ehdr *ehdr,
+		Elf64_Phdr *phdr)
+{
+	return phdr;
+}
+#endif /* CONFIG_CRASH_MEMACTION */
+
 /* time to wait for possible DMA to finish before starting the kdump kernel
  * when a CMA reservation is used
  */
@@ -142,6 +554,7 @@ void __noclone __crash_kexec(struct pt_regs *regs)
 			crash_save_vmcoreinfo();
 			machine_crash_shutdown(&fixed_regs);
 			crash_cma_clear_pending_dma();
+			crash_memaction_save(kexec_crash_image);
 			machine_kexec(kexec_crash_image);
 		}
 		kexec_unlock();
@@ -182,6 +595,7 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
 	/* extra phdr for vmcoreinfo ELF note */
 	nr_phdr = nr_cpus + 1;
 	nr_phdr += mem->nr_ranges;
+	nr_phdr += crash_memaction_nr_phdr();
 
 	/*
 	 * kexec-tools creates an extra PT_LOAD phdr for kernel text mapping
@@ -231,6 +645,8 @@ int crash_prepare_elf64_headers(struct crash_mem *mem, int need_kernel_map,
 	(ehdr->e_phnum)++;
 	phdr++;
 
+	phdr = crash_memaction_emit_phdr(ehdr, phdr);
+
 	/* Prepare PT_LOAD type program header for kernel text region */
 	if (need_kernel_map) {
 		phdr->p_type = PT_LOAD;
diff --git a/kernel/kexec_core.c b/kernel/kexec_core.c
index 7ee8c9f078f6..ac7406d68bdf 100644
--- a/kernel/kexec_core.c
+++ b/kernel/kexec_core.c
@@ -8,6 +8,7 @@
 
 #include <linux/btf.h>
 #include <linux/capability.h>
+#include <linux/crash_memaction.h>
 #include <linux/mm.h>
 #include <linux/file.h>
 #include <linux/slab.h>
@@ -264,6 +265,8 @@ struct kimage *do_kimage_alloc_init(void)
 	image->elfcorehdr_updated = false;
 #endif
 
+	image->memaction_index = -1;
+
 	return image;
 }
 
@@ -595,6 +598,7 @@ void kimage_free(struct kimage *image)
 		crash_update_vmcoreinfo_safecopy(NULL);
 		vunmap(image->vmcoreinfo_data_copy);
 	}
+	crash_memaction_unload(image);
 #endif
 
 	kimage_free_extra_pages(image);
diff --git a/kernel/kexec_file.c b/kernel/kexec_file.c
index a8455481f639..e87194524fd7 100644
--- a/kernel/kexec_file.c
+++ b/kernel/kexec_file.c
@@ -10,6 +10,7 @@
 #define pr_fmt(fmt) KBUILD_MODNAME ": " fmt
 
 #include <linux/capability.h>
+#include <linux/crash_memaction.h>
 #include <linux/mm.h>
 #include <linux/file.h>
 #include <linux/slab.h>
@@ -325,6 +326,10 @@ kimage_file_alloc_init(struct kimage **rimage, int kernel_fd,
 		/* Enable special crash kernel control page alloc policy. */
 		image->control_page = crashk_res.start;
 		image->type = KEXEC_TYPE_CRASH;
+
+		ret = crash_load_memaction(image);
+		if (ret)
+			goto out_free_image;
 	}
 #endif
 
@@ -360,6 +365,7 @@ kimage_file_alloc_init(struct kimage **rimage, int kernel_fd,
 out_free_post_load_bufs:
 	kimage_file_post_load_cleanup(image);
 out_free_image:
+	crash_memaction_unload(image);
 	kfree(image);
 	return ret;
 }
@@ -877,6 +883,10 @@ static int kexec_calculate_store_digests(struct kimage *image)
 			continue;
 #endif
 
+		/* Exclude the memaction buffer, written during the crash */
+		if (i == image->memaction_index)
+			continue;
+
 		ksegment = &image->segment[i];
 		/*
 		 * Skip purgatory as it will be modified once we put digest
diff --git a/kernel/ksysfs.c b/kernel/ksysfs.c
index f45ade718054..846bd850a4fb 100644
--- a/kernel/ksysfs.c
+++ b/kernel/ksysfs.c
@@ -14,6 +14,7 @@
 #include <linux/export.h>
 #include <linux/init.h>
 #include <linux/vmcore_info.h>
+#include <linux/crash_memaction.h>
 #include <linux/profile.h>
 #include <linux/stat.h>
 #include <linux/sched.h>
@@ -133,6 +134,17 @@ KERNEL_ATTR_RO(vmcoreinfo);
 
 #endif /* CONFIG_VMCORE_INFO */
 
+#ifdef CONFIG_CRASH_MEMACTION
+
+static ssize_t crash_memaction_show(struct kobject *kobj,
+				    struct kobj_attribute *attr, char *buf)
+{
+	return crash_memaction_types_str(buf);
+}
+KERNEL_ATTR_RO(crash_memaction);
+
+#endif /* CONFIG_CRASH_MEMACTION */
+
 /* whether file capabilities are enabled */
 static ssize_t fscaps_show(struct kobject *kobj,
 				  struct kobj_attribute *attr, char *buf)
@@ -203,6 +215,9 @@ static struct attribute * kernel_attrs[] = {
 #ifdef CONFIG_VMCORE_INFO
 	&vmcoreinfo_attr.attr,
 #endif
+#ifdef CONFIG_CRASH_MEMACTION
+	&crash_memaction_attr.attr,
+#endif
 #ifndef CONFIG_TINY_RCU
 	&rcu_expedited_attr.attr,
 	&rcu_normal_attr.attr,

-- 
2.55.0

Re: [PATCH v3 01/12] kexec: Add a crash memaction registry

[sashiko-bot]

> Add a registry identifying page use to a kdump kernel. Intended uses are
> wiping of crypto keys on crash, or omitting pages holding e.g. crypto
> keys or unimportant caches from crash dumps.
> 
> The registry is a bitmap with one bit for each physical page. The
> meaning of the bits is set by the crash_memaction= cmdline param. When
> not present, no bitmap is allocated. Marking is a lock-free bitmap
> update with no allocation, so it is safe from any context.
> 
> The bitmap and its metadata is handed over to the kdump kernel through
> elfcorehdr.
> 
> Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=1

[PATCH v3 02/12] lib, kexec: Add a secret pool for key material

[Jan Sebastian Götte]

Key material allocated with kmalloc() shares its slab pages with
unrelated allocations. crash_memaction marks memory at page granularity,
so smaller objects in shared slab pages can't cleanly be marked or
unmarked. This commit adds a secret pool built on kmem_buckets to
hold such keys in marked pages.

Allocations from the pool are marked CRASH_MEMACTION_SECRET. The
marking compiles to nothing without CONFIG_CRASH_MEMACTION, and stays
a no-op at runtime unless "secret" is among the types enabled on the
kernel command line.

The pool requires SLAB_BUCKETS, which in turn depends on !SLUB_TINY,
hence the new dependency for CRASH_MEMACTION. Without SLAB_BUCKETS,
allocations fall back to ordinary kmalloc allocations. The pool
likewise falls back to the ordinary kmalloc caches when it is used
before its initcall runs, or after pool creation failed.

Markings are set on object allocation since there's no clean way to hook
page allocation in kmem_buckets. This comes at a small per-allocation
overhead. Markings are cleared implicitly by the page allocator in
post_alloc_hook() when it hands out a reclaimed page to its next owner.

Using this pool for secrets has a useful side effect from a
defense-in-depth perspective. Where SLAB_BUCKETS is enabled, it keeps
secrets away from other kernel data, which makes UAF or out-of-bounds
read vulnerabilities less likely to reach secrets.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 MAINTAINERS                 |  2 ++
 include/linux/secret_pool.h | 47 +++++++++++++++++++++++++++++++++++++++++++++
 kernel/Kconfig.kexec        |  2 ++
 lib/Makefile                |  1 +
 lib/secret_pool.c           | 27 ++++++++++++++++++++++++++
 5 files changed, 79 insertions(+)

diff --git a/MAINTAINERS b/MAINTAINERS
index c6350fd34f4c..bcb11c2138bc 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14260,8 +14260,10 @@ F:	fs/proc/vmcore.c
 F:	include/linux/crash_core.h
 F:	include/linux/crash_dump.h
 F:	include/linux/crash_memaction.h
+F:	include/linux/secret_pool.h
 F:	include/uapi/linux/vmcore.h
 F:	kernel/crash_*.c
+F:	lib/secret_pool.c
 
 KEENE FM RADIO TRANSMITTER DRIVER
 M:	Hans Verkuil <hverkuil@kernel.org>
diff --git a/include/linux/secret_pool.h b/include/linux/secret_pool.h
new file mode 100644
index 000000000000..aa9296c981c5
--- /dev/null
+++ b/include/linux/secret_pool.h
@@ -0,0 +1,47 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+#ifndef _LINUX_SECRET_POOL_H
+#define _LINUX_SECRET_POOL_H
+
+#include <linux/gfp.h>
+#include <linux/numa.h>
+#include <linux/slab.h>
+#include <linux/types.h>
+
+void *secret_pool_alloc_node(size_t size, gfp_t flags, int node)
+	__alloc_size(1);
+
+static inline __alloc_size(1) void *secret_pool_alloc(size_t size, gfp_t flags)
+{
+	return secret_pool_alloc_node(size, flags, NUMA_NO_NODE);
+}
+
+static inline __alloc_size(1) void *secret_pool_zalloc_node(size_t size,
+							    gfp_t flags,
+							    int node)
+{
+	return secret_pool_alloc_node(size, flags | __GFP_ZERO, node);
+}
+
+static inline __alloc_size(1) void *secret_pool_zalloc(size_t size,
+						       gfp_t flags)
+{
+	return secret_pool_alloc_node(size, flags | __GFP_ZERO, NUMA_NO_NODE);
+}
+
+static inline void secret_pool_free(const void *objp)
+{
+	kfree_sensitive(objp);
+}
+
+#define secret_pool_alloc_obj(P, ...) \
+	__alloc_objs(secret_pool_alloc, default_gfp(__VA_ARGS__), typeof(P), 1)
+#define secret_pool_zalloc_obj(P, ...) \
+	__alloc_objs(secret_pool_zalloc, default_gfp(__VA_ARGS__), typeof(P), 1)
+#define secret_pool_alloc_flex(P, FAM, COUNT, ...) \
+	__alloc_flex(secret_pool_alloc, default_gfp(__VA_ARGS__), typeof(P), \
+		     FAM, COUNT)
+#define secret_pool_zalloc_flex(P, FAM, COUNT, ...) \
+	__alloc_flex(secret_pool_zalloc, default_gfp(__VA_ARGS__), typeof(P), \
+		     FAM, COUNT)
+
+#endif /* _LINUX_SECRET_POOL_H */
diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index f7326fa6476b..890c35199bea 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -186,6 +186,8 @@ config CRASH_MEMACTION
 	bool "Register kdump actions for certain memory ranges"
 	depends on CRASH_DUMP
 	depends on KEXEC_FILE
+	depends on !SLUB_TINY
+	select SLAB_BUCKETS
 	depends on ARCH_SUPPORTS_CRASH_MEMACTION
 	help
 	  Track pages that may require special handling by the kdump kernel:
diff --git a/lib/Makefile b/lib/Makefile
index 43421c39d21b..0e69633bd79f 100644
--- a/lib/Makefile
+++ b/lib/Makefile
@@ -60,6 +60,7 @@ obj-y += bcd.o sort.o parser.o debug_locks.o random32.o \
 	 once.o refcount.o rcuref.o usercopy.o errseq.o bucket_locks.o \
 	 generic-radix-tree.o bitmap-str.o
 obj-y += string_helpers.o
+obj-y += secret_pool.o
 obj-y += hexdump.o
 obj-$(CONFIG_TEST_HEXDUMP) += test_hexdump.o
 obj-y += kstrtox.o
diff --git a/lib/secret_pool.c b/lib/secret_pool.c
new file mode 100644
index 000000000000..62954847091a
--- /dev/null
+++ b/lib/secret_pool.c
@@ -0,0 +1,27 @@
+// SPDX-License-Identifier: GPL-2.0
+#include <linux/crash_memaction.h>
+#include <linux/export.h>
+#include <linux/init.h>
+#include <linux/secret_pool.h>
+#include <linux/slab.h>
+
+static kmem_buckets * secret_pool __ro_after_init;
+
+static int __init secret_pool_init(void)
+{
+	secret_pool = kmem_buckets_create("secret", 0, 0, 0, NULL);
+
+	return 0;
+}
+core_initcall(secret_pool_init);
+
+void *secret_pool_alloc_node(size_t size, gfp_t flags, int node)
+{
+	void *p = kmem_buckets_alloc_node_track_caller(secret_pool, size,
+						       flags, node);
+
+	crash_memaction_mark(p, size, CRASH_MEMACTION_SECRET);
+
+	return p;
+}
+EXPORT_SYMBOL_GPL(secret_pool_alloc_node);

-- 
2.55.0

Re: [PATCH v3 02/12] lib, kexec: Add a secret pool for key material

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] lib/secret_pool: fallback to shared kmalloc inadvertently marks entire pages as secret
--

commit 774a436bfd0576d919ce17b831096d5b8c8dbbb5
Author: Jan Sebastian Götte <linux@jaseg.de>

lib, kexec: Add a secret pool for key material
    
Key material allocated with kmalloc() shares its slab pages with
unrelated allocations. crash_memaction marks memory at page granularity,
so smaller objects in shared slab pages can't cleanly be marked or
unmarked. This commit adds a secret pool built on kmem_buckets to
hold such keys in marked pages.

> diff --git a/lib/secret_pool.c b/lib/secret_pool.c
> new file mode 100644
> index 0000000000000..62954847091a0
> --- /dev/null
> +++ b/lib/secret_pool.c
> @@ -0,0 +1,27 @@
[ ... ]
> +void *secret_pool_alloc_node(size_t size, gfp_t flags, int node)
> +{
> +	void *p = kmem_buckets_alloc_node_track_caller(secret_pool, size,
> +						       flags, node);
> +
> +	crash_memaction_mark(p, size, CRASH_MEMACTION_SECRET);
        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: High]
Does this unconditionally mark the allocation even if it falls back to a shared
kmalloc page?

The commit message notes that if the secret pool is used before its initcall
runs or if pool creation fails, allocations will fall back to ordinary kmalloc
caches.

Because crash_memaction_mark() operates at page granularity, wouldn't calling
it on a shared kmalloc page inadvertently mark the entire page (and unrelated
kernel objects sharing it) as a secret?

In the event of a crash, could this cause the kdump kernel to wipe or exclude
these shared pages, potentially destroying crash data?

> +
> +	return p;
> +}
> +EXPORT_SYMBOL_GPL(secret_pool_alloc_node);

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=2

[PATCH v3 03/12] mm: Wire up the crash memaction registry

[Jan Sebastian Götte]

Allocate the registry bitmap during boot and sync marked pages to the
bitmap.

The registry bitmap is handed over to the kdump kernel through physical
addresses and thus needs to be a single, physically contiguous range.

A marking lasts past free and until the page frame is handed out again
in post_alloc_hook() to account for stale data left in pages that are
mid-migration or currently being reclaimed. For the same reason the
unmark comes after any init_on_alloc zeroing.

A hugetlb folio coming out of the pool never passes through
post_alloc_hook(), so it drops the marking of its previous life in
dequeue_hugetlb_folio_node_exact() instead. A folio the pool got from
the page allocator was already cleared in post_alloc_hook.

The hooks sit behind a static key patched out unless the kernel was
booted with crash_memaction= to mitigate overhead when not used.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 mm/hugetlb.c    | 4 ++++
 mm/mm_init.c    | 3 +++
 mm/page_alloc.c | 6 ++++++
 3 files changed, 13 insertions(+)

diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index da980377d353..36f0c0d8f5f1 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -31,6 +31,7 @@
 #include <linux/numa.h>
 #include <linux/llist.h>
 #include <linux/cma.h>
+#include <linux/crash_memaction.h>
 #include <linux/migrate.h>
 #include <linux/nospec.h>
 #include <linux/delayacct.h>
@@ -1281,6 +1282,9 @@ static struct folio *dequeue_hugetlb_folio_node_exact(struct hstate *h,
 		folio_clear_hugetlb_freed(folio);
 		h->free_huge_pages--;
 		h->free_huge_pages_node[nid]--;
+
+		crash_memaction_unmark_pfns(folio_pfn(folio),
+					    folio_nr_pages(folio));
 		return folio;
 	}
 
diff --git a/mm/mm_init.c b/mm/mm_init.c
index 9ce6060de06d..2245972b2685 100644
--- a/mm/mm_init.c
+++ b/mm/mm_init.c
@@ -27,6 +27,7 @@
 #include <linux/stackdepot.h>
 #include <linux/swap.h>
 #include <linux/cma.h>
+#include <linux/crash_memaction.h>
 #include <linux/crash_dump.h>
 #include <linux/execmem.h>
 #include <linux/sizes.h>
@@ -2706,6 +2707,8 @@ void __init mm_core_init(void)
 	 */
 	kho_memory_init();
 
+	crash_memaction_init();
+
 	memblock_free_all();
 	mem_init();
 	kmem_cache_init();
diff --git a/mm/page_alloc.c b/mm/page_alloc.c
index 759786240af3..ff82f632dc7d 100644
--- a/mm/page_alloc.c
+++ b/mm/page_alloc.c
@@ -54,6 +54,7 @@
 #include <linux/khugepaged.h>
 #include <linux/delayacct.h>
 #include <linux/cacheinfo.h>
+#include <linux/crash_memaction.h>
 #include <linux/pgalloc_tag.h>
 #include <asm/div64.h>
 #include "internal.h"
@@ -1854,6 +1855,11 @@ inline void post_alloc_hook(struct page *page, unsigned int order,
 	set_page_owner(page, order, gfp_flags);
 	page_table_check_alloc(page, order);
 	pgalloc_tag_add(page, current, 1 << order, alloc_flags);
+
+	/*
+	 * Release leftover crash_memaction markings from a previous owner of this page.
+	 */
+	crash_memaction_unmark_pfns(page_to_pfn(page), 1UL << order);
 }
 
 static void prep_new_page(struct page *page, unsigned int order, gfp_t gfp_flags,

-- 
2.55.0

Re: [PATCH v3 03/12] mm: Wire up the crash memaction registry

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: Stale secret data exposed due to premature unmarking of hugetlb folios
--

commit 62d401cf60aea442c3fea654492895fe956cadd9
Author: Jan Sebastian Götte <linux@jaseg.de>

mm: Wire up the crash memaction registry

This commit allocates the crash memaction registry bitmap during boot and
syncs marked pages to it. It introduces hooks to unmark pages when they are
handed out, placing the unmark after zeroing for page allocator folios, and
in dequeue_hugetlb_folio_node_exact for hugetlb folios.

> diff --git a/mm/hugetlb.c b/mm/hugetlb.c
> index da980377d3533..36f0c0d8f5f14 100644
> --- a/mm/hugetlb.c
> +++ b/mm/hugetlb.c

[ ... ]

> @@ -1281,6 +1282,9 @@ static struct folio *dequeue_hugetlb_folio_node_exact(struct hstate *h,
>  		folio_clear_hugetlb_freed(folio);
>  		h->free_huge_pages--;
>  		h->free_huge_pages_node[nid]--;
> +
> +		crash_memaction_unmark_pfns(folio_pfn(folio),
> +					    folio_nr_pages(folio));

[Severity: High]
Can this expose stale secret data to a crash dump if a crash occurs before
the folio is zeroed?

When a hugetlb folio containing secret data is freed to the hugetlb pool, it
retains its crash_memaction mark. When dequeued here in
dequeue_hugetlb_folio_node_exact(), it is unconditionally unmarked before
being returned.

Because the caller is responsible for zeroing the folio later via
folio_zero_user(), a window exists where the kdump kernel could observe an
unmarked folio and include its unzeroed secret data in the dump.

(Note: A similar window appears to exist for THP allocations when
init_on_alloc=0 because THP is allocated without __GFP_ZERO, causing
post_alloc_hook() to unmark it before the fault handler zeroes it.)

Could this unmarking be delayed until after the folio is zeroed?

>  		return folio;
>  	}

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=3

[PATCH v3 04/12] arm64: Enable the crash memaction registry

[Jan Sebastian Götte]

Select ARCH_SUPPORTS_CRASH_MEMACTION on arm64.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 arch/arm64/Kconfig | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
index 54c344d39830..4894a5cc11ac 100644
--- a/arch/arm64/Kconfig
+++ b/arch/arm64/Kconfig
@@ -1720,6 +1720,9 @@ config ARCH_SUPPORTS_KEXEC_HANDOVER
 config ARCH_SUPPORTS_CRASH_DUMP
 	def_bool y
 
+config ARCH_SUPPORTS_CRASH_MEMACTION
+	def_bool y
+
 config ARCH_DEFAULT_CRASH_DUMP
 	def_bool y
 

-- 
2.55.0

Re: [PATCH v3 04/12] arm64: Enable the crash memaction registry

[sashiko-bot]

> Select ARCH_SUPPORTS_CRASH_MEMACTION on arm64.
> 
> Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=4

[PATCH v3 05/12] dm crypt: Allocate key material from the secret pool

[Jan Sebastian Götte]

dm-crypt keeps the volume key, the IV mode seeds and, when a keyring key
is used, the key description in memory for as long as the target exists.
If the system crashes, they are left in memory and will end up in a
crash dump.

Allocate every buffer that holds key material from the new secret pool,
whose backing pages are marked by crash_memaction for the kdump kernel
to wipe. The volume key is a flexible array at the end of struct
crypt_config, so the whole struct moves into the pool with it.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 drivers/md/dm-crypt.c | 19 ++++++++++++-------
 1 file changed, 12 insertions(+), 7 deletions(-)

diff --git a/drivers/md/dm-crypt.c b/drivers/md/dm-crypt.c
index 8e838530faab..c386b4824629 100644
--- a/drivers/md/dm-crypt.c
+++ b/drivers/md/dm-crypt.c
@@ -29,6 +29,7 @@
 #include <linux/atomic.h>
 #include <linux/scatterlist.h>
 #include <linux/rbtree.h>
+#include <linux/secret_pool.h>
 #include <linux/ctype.h>
 #include <asm/page.h>
 #include <linux/unaligned.h>
@@ -486,7 +487,7 @@ static int crypt_iv_lmk_ctr(struct crypt_config *cc, struct dm_target *ti,
 		return 0;
 	}
 
-	lmk->seed = kzalloc(LMK_SEED_SIZE, GFP_KERNEL);
+	lmk->seed = secret_pool_zalloc(LMK_SEED_SIZE, GFP_KERNEL);
 	if (!lmk->seed) {
 		ti->error = "Error kmallocing seed storage in LMK";
 		return -ENOMEM;
@@ -603,8 +604,8 @@ static int crypt_iv_tcw_ctr(struct crypt_config *cc, struct dm_target *ti,
 		return -EINVAL;
 	}
 
-	tcw->iv_seed = kzalloc(cc->iv_size, GFP_KERNEL);
-	tcw->whitening = kzalloc(TCW_WHITENING_SIZE, GFP_KERNEL);
+	tcw->iv_seed = secret_pool_zalloc(cc->iv_size, GFP_KERNEL);
+	tcw->whitening = secret_pool_zalloc(TCW_WHITENING_SIZE, GFP_KERNEL);
 	if (!tcw->iv_seed || !tcw->whitening) {
 		crypt_iv_tcw_dtr(cc);
 		ti->error = "Error allocating seed storage in TCW";
@@ -771,7 +772,7 @@ static int crypt_iv_elephant_ctr(struct crypt_config *cc, struct dm_target *ti,
 	struct iv_elephant_private *elephant = &cc->iv_gen_private.elephant;
 	int r;
 
-	elephant->key = kmalloc_obj(*elephant->key);
+	elephant->key = secret_pool_alloc_obj(*elephant->key);
 	if (!elephant->key)
 		return -ENOMEM;
 
@@ -2484,6 +2485,7 @@ static int set_key_trusted(struct crypt_config *cc, struct key *key)
 static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string)
 {
 	char *new_key_string, *key_desc;
+	size_t key_string_size;
 	int ret;
 	struct key_type *type;
 	struct key *key;
@@ -2521,9 +2523,11 @@ static int crypt_set_keyring_key(struct crypt_config *cc, const char *key_string
 		return -EINVAL;
 	}
 
-	new_key_string = kstrdup(key_string, GFP_KERNEL);
+	key_string_size = strlen(key_string) + 1;
+	new_key_string = secret_pool_alloc(key_string_size, GFP_KERNEL);
 	if (!new_key_string)
 		return -ENOMEM;
+	memcpy(new_key_string, key_string, key_string_size);
 
 	key = request_key(type, key_desc + 1, NULL);
 	if (IS_ERR(key)) {
@@ -2851,7 +2855,8 @@ static int crypt_ctr_auth_cipher(struct crypt_config *cc, char *cipher_api)
 		cc->key_mac_size = crypto_ahash_digestsize(mac);
 	crypto_free_ahash(mac);
 
-	cc->authenc_key = kmalloc(crypt_authenckey_size(cc), GFP_KERNEL);
+	cc->authenc_key = secret_pool_alloc(crypt_authenckey_size(cc),
+					    GFP_KERNEL);
 	if (!cc->authenc_key)
 		return -ENOMEM;
 
@@ -3201,7 +3206,7 @@ static int crypt_ctr(struct dm_target *ti, unsigned int argc, char **argv)
 		return -EINVAL;
 	}
 
-	cc = kzalloc_flex(*cc, key, key_size);
+	cc = secret_pool_zalloc_flex(*cc, key, key_size);
 	if (!cc) {
 		ti->error = "Cannot allocate encryption context";
 		return -ENOMEM;

-- 
2.55.0

Re: [PATCH v3 05/12] dm crypt: Allocate key material from the secret pool

[sashiko-bot]

> dm-crypt keeps the volume key, the IV mode seeds and, when a keyring key
> is used, the key description in memory for as long as the target exists.
> If the system crashes, they are left in memory and will end up in a
> crash dump.
> 
> Allocate every buffer that holds key material from the new secret pool,
> whose backing pages are marked by crash_memaction for the kdump kernel
> to wipe. The volume key is a flexible array at the end of struct
> crypt_config, so the whole struct moves into the pool with it.
> 
> Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=5

[PATCH v3 06/12] crypto: api - Allocate tfms from the secret pool

[Jan Sebastian Götte]

A tfm's context holds the expanded key schedule, which a crash dump
would capture.

Allocate tfms from the secret pool, so that their backing pages are
marked by crash_memaction for the kdump kernel to wipe.
The context is a flexible array at the end of struct crypto_tfm and the
frontend's private data sits in front of the struct, so the whole
allocation moves into the pool.

Allocation cost increases by a bucket lookup in crash_memaction. Freeing
is unchanged.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 crypto/api.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/crypto/api.c b/crypto/api.c
index 24227582cfcf..eba310f128dc 100644
--- a/crypto/api.c
+++ b/crypto/api.c
@@ -18,6 +18,7 @@
 #include <linux/module.h>
 #include <linux/param.h>
 #include <linux/sched/signal.h>
+#include <linux/secret_pool.h>
 #include <linux/slab.h>
 #include <linux/string.h>
 #include <linux/completion.h>
@@ -413,7 +414,7 @@ struct crypto_tfm *__crypto_alloc_tfm(struct crypto_alg *alg, u32 type,
 	int err = -ENOMEM;
 
 	tfm_size = sizeof(*tfm) + crypto_ctxsize(alg, type, mask);
-	tfm = kzalloc(tfm_size, GFP_KERNEL);
+	tfm = secret_pool_zalloc(tfm_size, GFP_KERNEL);
 	if (tfm == NULL)
 		goto out_err;
 
@@ -428,7 +429,7 @@ struct crypto_tfm *__crypto_alloc_tfm(struct crypto_alg *alg, u32 type,
 	crypto_exit_ops(tfm);
 	if (err == -EAGAIN)
 		crypto_shoot_alg(alg);
-	kfree(tfm);
+	kfree_sensitive(tfm);
 out_err:
 	tfm = ERR_PTR(err);
 out:
@@ -502,7 +503,7 @@ void *crypto_create_tfm_node(struct crypto_alg *alg,
 	int err;
 
 	size = frontend->tfmsize + sizeof(*tfm) + frontend->extsize(alg);
-	mem = kzalloc_node(size, GFP_KERNEL, node);
+	mem = secret_pool_zalloc_node(size, GFP_KERNEL, node);
 	if (!mem)
 		return ERR_PTR(-ENOMEM);
 
@@ -525,7 +526,7 @@ void *crypto_create_tfm_node(struct crypto_alg *alg,
 out_free_tfm:
 	if (err == -EAGAIN)
 		crypto_shoot_alg(alg);
-	kfree(mem);
+	kfree_sensitive(mem);
 	mem = ERR_PTR(err);
 out:
 	return mem;

-- 
2.55.0

Re: [PATCH v3 06/12] crypto: api - Allocate tfms from the secret pool

[sashiko-bot]

> A tfm's context holds the expanded key schedule, which a crash dump
> would capture.
> 
> Allocate tfms from the secret pool, so that their backing pages are
> marked by crash_memaction for the kdump kernel to wipe.
> The context is a flexible array at the end of struct crypto_tfm and the
> frontend's private data sits in front of the struct, so the whole
> allocation moves into the pool.
> 
> Allocation cost increases by a bucket lookup in crash_memaction. Freeing
> is unchanged.
> 
> Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=6

[PATCH v3 07/12] security/keys: Allocate key payloads from the secret pool

[Jan Sebastian Götte]

Key payloads sit in memory in plain text for as long as the key exists,
and a kdump crash dump captures them along with everything else.

Allocate the payloads of the user-defined, trusted and encrypted key
types from the new secret pool, so that their backing pages are marked
by crash_memaction for the kdump kernel to wipe.

This commit covers the key types used by dm-crypt/cryptsetup. Additional
key types can be added if needed in future commits.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 security/keys/encrypted-keys/encrypted.c  | 5 +++--
 security/keys/trusted-keys/trusted_core.c | 3 ++-
 security/keys/user_defined.c              | 3 ++-
 3 files changed, 7 insertions(+), 4 deletions(-)

diff --git a/security/keys/encrypted-keys/encrypted.c b/security/keys/encrypted-keys/encrypted.c
index e07092ea301a..633f31131867 100644
--- a/security/keys/encrypted-keys/encrypted.c
+++ b/security/keys/encrypted-keys/encrypted.c
@@ -27,6 +27,7 @@
 #include <linux/random.h>
 #include <linux/rcupdate.h>
 #include <linux/scatterlist.h>
+#include <linux/secret_pool.h>
 #include <linux/ctype.h>
 #include <crypto/aes.h>
 #include <crypto/sha2.h>
@@ -648,8 +649,8 @@ static struct encrypted_key_payload *encrypted_key_alloc(struct key *key,
 	if (ret < 0)
 		return ERR_PTR(ret);
 
-	epayload = kzalloc_flex(*epayload, payload_data, payload_totallen,
-				GFP_KERNEL);
+	epayload = secret_pool_zalloc_flex(*epayload, payload_data,
+					   payload_totallen, GFP_KERNEL);
 	if (!epayload)
 		return ERR_PTR(-ENOMEM);
 
diff --git a/security/keys/trusted-keys/trusted_core.c b/security/keys/trusted-keys/trusted_core.c
index 0509d9955f2a..5f209c5f3f14 100644
--- a/security/keys/trusted-keys/trusted_core.c
+++ b/security/keys/trusted-keys/trusted_core.c
@@ -22,6 +22,7 @@
 #include <linux/parser.h>
 #include <linux/random.h>
 #include <linux/rcupdate.h>
+#include <linux/secret_pool.h>
 #include <linux/slab.h>
 #include <linux/static_call.h>
 #include <linux/string.h>
@@ -140,7 +141,7 @@ static struct trusted_key_payload *trusted_payload_alloc(struct key *key)
 	ret = key_payload_reserve(key, sizeof(*p));
 	if (ret < 0)
 		goto err;
-	p = kzalloc_obj(*p);
+	p = secret_pool_zalloc_obj(*p);
 	if (!p)
 		goto err;
 
diff --git a/security/keys/user_defined.c b/security/keys/user_defined.c
index 6f88b507f927..dce2508587df 100644
--- a/security/keys/user_defined.c
+++ b/security/keys/user_defined.c
@@ -7,6 +7,7 @@
 
 #include <linux/export.h>
 #include <linux/init.h>
+#include <linux/secret_pool.h>
 #include <linux/slab.h>
 #include <linux/seq_file.h>
 #include <linux/err.h>
@@ -64,7 +65,7 @@ int user_preparse(struct key_preparsed_payload *prep)
 	if (datalen == 0 || datalen > 32767 || !prep->data)
 		return -EINVAL;
 
-	upayload = kmalloc_flex(*upayload, data, datalen);
+	upayload = secret_pool_alloc_flex(*upayload, data, datalen);
 	if (!upayload)
 		return -ENOMEM;
 

-- 
2.55.0

Re: [PATCH v3 07/12] security/keys: Allocate key payloads from the secret pool

[sashiko-bot]

> Key payloads sit in memory in plain text for as long as the key exists,
> and a kdump crash dump captures them along with everything else.
> 
> Allocate the payloads of the user-defined, trusted and encrypted key
> types from the new secret pool, so that their backing pages are marked
> by crash_memaction for the kdump kernel to wipe.
> 
> This commit covers the key types used by dm-crypt/cryptsetup. Additional
> key types can be added if needed in future commits.
> 
> Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=7

[PATCH v3 08/12] mm: Add VM_CRASH_MARK

[Jan Sebastian Götte]

Add a VMA flag saying that the folios mapped into a VMA should be
described to the kdump kernel through crash_memaction. The flag
indicates "marked" pages. The specific meaning of what pages are marked
is set through the crash_memaction= cmdline param, which currently
supports marking "secret" or "cache" pages.

The flag is an ordinary VMA flag, so splitting, merging, mremap() and
inheritance across fork() all behave the way they do for MADV_DONTFORK
and friends.

To allocate the flag, CONFIG_CRASH_MEMACTION gains a dependency on
64BIT. Both architectures that support the config are 64-bit already.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 fs/proc/task_mmu.c   | 3 +++
 include/linux/mm.h   | 9 +++++++++
 kernel/Kconfig.kexec | 2 ++
 3 files changed, 14 insertions(+)

diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
index c0d228036b8a..880946edf4df 100644
--- a/fs/proc/task_mmu.c
+++ b/fs/proc/task_mmu.c
@@ -1161,6 +1161,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
 #endif
 #ifdef CONFIG_64BIT
 		[ilog2(VM_SEALED)] = "sl",
+#endif
+#ifdef CONFIG_CRASH_MEMACTION
+		[ilog2(VM_CRASH_MARK)] = "cm",
 #endif
 	};
 	size_t i;
diff --git a/include/linux/mm.h b/include/linux/mm.h
index b9ed4f569b75..4ffe6350f865 100644
--- a/include/linux/mm.h
+++ b/include/linux/mm.h
@@ -345,6 +345,10 @@ enum {
 	DECLARE_VMA_BIT(UFFD_MINOR, 41),
 	DECLARE_VMA_BIT(SEALED, 42),
 	DECLARE_VMA_BIT(UFFD_RWP, 43),
+#if defined(CONFIG_CRASH_MEMACTION)
+	/* Describe this VMA's folios to the kdump kernel; carries no type. */
+	DECLARE_VMA_BIT(CRASH_MARK, 44),
+#endif
 	/* Flags that reuse flags above. */
 	DECLARE_VMA_BIT_ALIAS(PKEY_BIT0, HIGH_ARCH_0),
 	DECLARE_VMA_BIT_ALIAS(PKEY_BIT1, HIGH_ARCH_1),
@@ -526,6 +530,11 @@ enum {
 #define VM_ALLOW_ANY_UNCACHED	VM_NONE
 #define VM_SEALED		VM_NONE
 #endif
+#ifdef CONFIG_CRASH_MEMACTION
+#define VM_CRASH_MARK		INIT_VM_FLAG(CRASH_MARK)
+#else
+#define VM_CRASH_MARK		VM_NONE
+#endif
 #if defined(CONFIG_64BIT) || defined(CONFIG_PPC32)
 #define VM_DROPPABLE		INIT_VM_FLAG(DROPPABLE)
 #define VMA_DROPPABLE		mk_vma_flags(VMA_DROPPABLE_BIT)
diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index 890c35199bea..3cdc8d459ac0 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -189,6 +189,8 @@ config CRASH_MEMACTION
 	depends on !SLUB_TINY
 	select SLAB_BUCKETS
 	depends on ARCH_SUPPORTS_CRASH_MEMACTION
+	# VM_CRASH_MARK needs a bit from the 64-bit-only half of vm_flags.
+	depends on 64BIT
 	help
 	  Track pages that may require special handling by the kdump kernel:
 	  pages holding secrets such as crypto keys, which it can wipe before

-- 
2.55.0

Re: [PATCH v3 08/12] mm: Add VM_CRASH_MARK

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 2 potential issue(s) to consider:
- [Low] mm: VM_CRASH_MARK missing from ftrace mmflags VMA flag definitions
- [Low] mm: proc.rst missing documentation for 'cm' VmFlags mnemonic
--

commit 7b00e78975a449ed080eb0472f9ec80a85b781f6
Author: Jan Sebastian Götte <linux@jaseg.de>

mm: Add VM_CRASH_MARK

This commit adds a new VMA flag, VM_CRASH_MARK, to describe folios mapped
into a VMA to the kdump kernel through crash_memaction. The flag indicates
pages to be handled based on the cmdline param, such as secret or cache
pages.

> diff --git a/fs/proc/task_mmu.c b/fs/proc/task_mmu.c
> index c0d228036b8a6..880946edf4dfa 100644
> --- a/fs/proc/task_mmu.c
> +++ b/fs/proc/task_mmu.c
> @@ -1161,6 +1161,9 @@ static void show_smap_vma_flags(struct seq_file *m, struct vm_area_struct *vma)
>  #endif
>  #ifdef CONFIG_64BIT
>  		[ilog2(VM_SEALED)] = "sl",
> +#endif
> +#ifdef CONFIG_CRASH_MEMACTION
> +		[ilog2(VM_CRASH_MARK)] = "cm",

[Severity: Low]
Since this adds the new cm mnemonic to the smaps output in show_smap_vma_flags(),
shouldn't this also be documented in Documentation/filesystems/proc.rst so users
reading the smaps file can understand what the string means?

>  #endif
>  	};
>  	size_t i;
> diff --git a/include/linux/mm.h b/include/linux/mm.h
> index b9ed4f569b75f..4ffe6350f8655 100644
> --- a/include/linux/mm.h
> +++ b/include/linux/mm.h
[ ... ]
> @@ -526,6 +530,11 @@ enum {
>  #define VM_ALLOW_ANY_UNCACHED	VM_NONE
>  #define VM_SEALED		VM_NONE
>  #endif
> +#ifdef CONFIG_CRASH_MEMACTION
> +#define VM_CRASH_MARK		INIT_VM_FLAG(CRASH_MARK)

[Severity: Low]
When defining a new VMA flag here, does it also need to be registered in the
__def_vmaflag_names array in include/trace/events/mmflags.h?

If it is omitted, tracing tools capturing mmap or madvise events might output
an unknown hexadecimal bit instead of the human-readable crash_mark flag.

> +#else
> +#define VM_CRASH_MARK		VM_NONE
> +#endif

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=8

[PATCH v3 09/12] mm/rmap: Mark folios mapped into crash_memaction-marked VMAs

[Jan Sebastian Götte]

Propagate crash_memaction marks set through madvise() to the
crash_memaction registry. Register the folios of a VMA carrying
VM_CRASH_MARK with the crash memaction registry as they are mapped, and
update the registry when a folio moves.

Marks are processed in rmap since the fault paths, CoW, swapin,
migration and khugepaged collapse all converge here. The marks don't
affect pinning, reclaim, compaction or hot-unplug. De-regsitering free'd
marked pages is done in post_alloc_hook() and the hugetlb pool to
account for stale data in free'd pages.

The marking code is gated behind a static key that is only enabled when
the crash_memaction registry is explicitly enabled by a cmdline
argument, so there should be no performance impact unless the feature is
actually used.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 include/linux/crash_memaction.h | 15 +++++++++++++++
 include/linux/rmap.h            |  5 ++++-
 mm/huge_memory.c                |  2 ++
 mm/hugetlb.c                    |  6 +++---
 mm/migrate.c                    |  2 +-
 mm/rmap.c                       |  8 ++++++++
 mm/userfaultfd.c                |  1 +
 7 files changed, 34 insertions(+), 5 deletions(-)

diff --git a/include/linux/crash_memaction.h b/include/linux/crash_memaction.h
index 5f3e114c60ad..2de60bc12dd9 100644
--- a/include/linux/crash_memaction.h
+++ b/include/linux/crash_memaction.h
@@ -4,6 +4,7 @@
 
 #include <linux/init.h>
 #include <linux/jump_label.h>
+#include <linux/mm.h>
 #include <linux/types.h>
 
 struct kimage;
@@ -50,6 +51,18 @@ static inline void crash_memaction_unmark_pfns(unsigned long pfn,
 		__crash_memaction_unmark_pfns(pfn, nr_pages);
 }
 
+static inline void crash_mark_pages(struct page *page, int nr_pages,
+		struct vm_area_struct *vma)
+{
+	if (!static_branch_unlikely(&crash_memaction_active))
+		return;
+
+	if (likely(!(vma->vm_flags & VM_CRASH_MARK)))
+		return;
+
+	__crash_memaction_mark_pfns(page_to_pfn(page), nr_pages);
+}
+
 void crash_memaction_mark(void *addr, size_t size, int types);
 void crash_memaction_unmark(void *addr, size_t size);
 
@@ -62,6 +75,8 @@ void crash_memaction_unload(struct kimage *image);
 static inline void crash_memaction_init(void) { }
 static inline void crash_memaction_unmark_pfns(unsigned long pfn,
 		unsigned long nr_pages) { }
+static inline void crash_mark_pages(struct page *page, int nr_pages,
+		struct vm_area_struct *vma) { }
 static inline void crash_memaction_mark(void *addr, size_t size, int types) { }
 static inline void crash_memaction_unmark(void *addr, size_t size) { }
 static inline int crash_memaction_types(void) { return 0; }
diff --git a/include/linux/rmap.h b/include/linux/rmap.h
index 74cca0e3c726..1eeb7762b4a3 100644
--- a/include/linux/rmap.h
+++ b/include/linux/rmap.h
@@ -9,6 +9,7 @@
 #include <linux/slab.h>
 #include <linux/mm.h>
 #include <linux/rwsem.h>
+#include <linux/crash_memaction.h>
 #include <linux/memcontrol.h>
 #include <linux/highmem.h>
 #include <linux/pagemap.h>
@@ -472,13 +473,15 @@ static inline int hugetlb_try_share_anon_rmap(struct folio *folio)
 	return 0;
 }
 
-static inline void hugetlb_add_file_rmap(struct folio *folio)
+static inline void hugetlb_add_file_rmap(struct folio *folio,
+		struct vm_area_struct *vma)
 {
 	VM_WARN_ON_FOLIO(!folio_test_hugetlb(folio), folio);
 	VM_WARN_ON_FOLIO(folio_test_anon(folio), folio);
 
 	atomic_inc(&folio->_entire_mapcount);
 	atomic_inc(&folio->_large_mapcount);
+	crash_mark_pages(&folio->page, folio_nr_pages(folio), vma);
 }
 
 static inline void hugetlb_remove_rmap(struct folio *folio)
diff --git a/mm/huge_memory.c b/mm/huge_memory.c
index 3fb9504dff7a..adbda968d58e 100644
--- a/mm/huge_memory.c
+++ b/mm/huge_memory.c
@@ -2966,6 +2966,8 @@ int move_pages_huge_pmd(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, pm
 
 		folio_move_anon_rmap(src_folio, dst_vma);
 		src_folio->index = linear_anon_page_index(dst_vma, dst_addr);
+		/* No rmap add, and the two VMAs need not agree on the flag. */
+		crash_mark_pages(&src_folio->page, HPAGE_PMD_NR, dst_vma);
 
 		_dst_pmd = folio_mk_pmd(src_folio, dst_vma->vm_page_prot);
 		/* Follow mremap() behavior and treat the entry dirty after the move */
diff --git a/mm/hugetlb.c b/mm/hugetlb.c
index 36f0c0d8f5f1..309be0b301ca 100644
--- a/mm/hugetlb.c
+++ b/mm/hugetlb.c
@@ -5063,7 +5063,7 @@ int copy_hugetlb_page_range(struct mm_struct *dst, struct mm_struct *src,
 			 * sleep during the process.
 			 */
 			if (!folio_test_anon(pte_folio)) {
-				hugetlb_add_file_rmap(pte_folio);
+				hugetlb_add_file_rmap(pte_folio, dst_vma);
 			} else if (hugetlb_try_dup_anon_rmap(pte_folio, src_vma)) {
 				pte_t src_pte_old = entry;
 				struct folio *new_folio;
@@ -5982,7 +5982,7 @@ static vm_fault_t hugetlb_no_page(struct address_space *mapping,
 	if (new_anon_folio)
 		hugetlb_add_new_anon_rmap(folio, vma, vmf->address);
 	else
-		hugetlb_add_file_rmap(folio);
+		hugetlb_add_file_rmap(folio, vma);
 	new_pte = make_huge_pte(vma, folio, vma->vm_flags & VM_SHARED);
 	/*
 	 * If this pte was previously wr-protected, keep it wr-protected even
@@ -6502,7 +6502,7 @@ int hugetlb_mfill_atomic_pte(pte_t *dst_pte,
 		goto out_release_unlock;
 
 	if (folio_in_pagecache)
-		hugetlb_add_file_rmap(folio);
+		hugetlb_add_file_rmap(folio, dst_vma);
 	else
 		hugetlb_add_new_anon_rmap(folio, dst_vma, dst_addr);
 
diff --git a/mm/migrate.c b/mm/migrate.c
index 7bdcdb57652f..467b695e6dd6 100644
--- a/mm/migrate.c
+++ b/mm/migrate.c
@@ -434,7 +434,7 @@ static bool remove_migration_pte(struct folio *folio,
 				hugetlb_add_anon_rmap(folio, vma, pvmw.address,
 						      rmap_flags);
 			else
-				hugetlb_add_file_rmap(folio);
+				hugetlb_add_file_rmap(folio, vma);
 			set_huge_pte_at(vma->vm_mm, pvmw.address, pvmw.pte, pte,
 					psize);
 		} else
diff --git a/mm/rmap.c b/mm/rmap.c
index fbd66a2823b7..21183478f606 100644
--- a/mm/rmap.c
+++ b/mm/rmap.c
@@ -1582,6 +1582,8 @@ static __always_inline void __folio_add_anon_rmap(struct folio *folio,
 	 */
 	if (folio_nr_pages(folio) == nr_pages)
 		mlock_vma_folio(folio, vma);
+
+	crash_mark_pages(page, nr_pages, vma);
 }
 
 /**
@@ -1703,6 +1705,8 @@ void folio_add_new_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
 
 	__folio_mod_stat(folio, nr, nr_pmdmapped);
 	mod_mthp_stat(folio_order(folio), MTHP_STAT_NR_ANON, 1);
+
+	crash_mark_pages(&folio->page, nr, vma);
 }
 
 static __always_inline void __folio_add_file_rmap(struct folio *folio,
@@ -1721,6 +1725,8 @@ static __always_inline void __folio_add_file_rmap(struct folio *folio,
 	 */
 	if (folio_nr_pages(folio) == nr_pages)
 		mlock_vma_folio(folio, vma);
+
+	crash_mark_pages(page, nr_pages, vma);
 }
 
 /**
@@ -3190,6 +3196,7 @@ void hugetlb_add_anon_rmap(struct folio *folio, struct vm_area_struct *vma,
 		SetPageAnonExclusive(&folio->page);
 	VM_WARN_ON_FOLIO(folio_entire_mapcount(folio) > 1 &&
 			 PageAnonExclusive(&folio->page), folio);
+	crash_mark_pages(&folio->page, folio_nr_pages(folio), vma);
 }
 
 void hugetlb_add_new_anon_rmap(struct folio *folio,
@@ -3204,5 +3211,6 @@ void hugetlb_add_new_anon_rmap(struct folio *folio,
 	folio_clear_hugetlb_restore_reserve(folio);
 	__folio_set_anon(folio, vma, address, true);
 	SetPageAnonExclusive(&folio->page);
+	crash_mark_pages(&folio->page, folio_nr_pages(folio), vma);
 }
 #endif /* CONFIG_HUGETLB_PAGE */
diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
index b242fa8b22c8..bb0a35d59daa 100644
--- a/mm/userfaultfd.c
+++ b/mm/userfaultfd.c
@@ -1326,6 +1326,7 @@ static long move_present_ptes(struct mm_struct *mm,
 
 		folio_move_anon_rmap(src_folio, dst_vma);
 		src_folio->index = linear_anon_page_index(dst_vma, dst_addr);
+		crash_mark_pages(&src_folio->page, 1, dst_vma);
 
 		orig_dst_pte = folio_mk_pte(src_folio, dst_vma->vm_page_prot);
 		/* Set soft dirty bit so userspace can notice the pte was moved */

-- 
2.55.0

Re: [PATCH v3 09/12] mm/rmap: Mark folios mapped into crash_memaction-marked VMAs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 3 potential issue(s) to consider:
- [Medium] mm/userfaultfd: UFFDIO_MOVE misses crash_memaction registration for swap cache
- [Medium] mm: stale crash_memaction marks when moving pages to unmarked VMAs
- [Low] mm/rmap: data race on vma->vm_flags in crash_mark_pages()
--

commit 78115d9186907359bdb879efc1ef14d161aac39a
Author: Jan Sebastian Götte <linux@jaseg.de>
Subject: mm/rmap: Mark folios mapped into crash_memaction-marked VMAs

This patch propagates crash_memaction marks set through madvise() to the
crash_memaction registry. It registers folios of a VMA carrying VM_CRASH_MARK
as they are mapped, and updates the registry when a folio moves. It also hooks
into the free path to deregister pages and avoid tracking stale data.

> diff --git a/include/linux/crash_memaction.h b/include/linux/crash_memaction.h
> index 5f3e114c60ad7..2de60bc12dd9f 100644
> --- a/include/linux/crash_memaction.h
> +++ b/include/linux/crash_memaction.h
[ ... ]
> @@ -50,6 +51,18 @@ static inline void crash_memaction_unmark_pfns(unsigned long pfn,
>  		__crash_memaction_unmark_pfns(pfn, nr_pages);
>  }
>  
> +static inline void crash_mark_pages(struct page *page, int nr_pages,
> +		struct vm_area_struct *vma)
> +{
> +	if (!static_branch_unlikely(&crash_memaction_active))
> +		return;
> +
> +	if (likely(!(vma->vm_flags & VM_CRASH_MARK)))
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Low]
Should this lockless read of vma->vm_flags use READ_ONCE()?

The crash_mark_pages() function is called via folio_add_anon_rmap_ptes()
during migration (such as in remove_migration_pte()) holding only the
anon_vma lock. At the same time, mprotect() can update vma->vm_flags
while holding the VMA lock, but not the anon_vma lock. 

Could this concurrent modification lead to a data race or torn reads during
migration?

> +		return;
> +
> +	__crash_memaction_mark_pfns(page_to_pfn(page), nr_pages);
> +}
> +
>  void crash_memaction_mark(void *addr, size_t size, int types);
>  void crash_memaction_unmark(void *addr, size_t size);
>  
[ ... ]
> diff --git a/mm/huge_memory.c b/mm/huge_memory.c
> index 3fb9504dff7a9..adbda968d58ef 100644
> --- a/mm/huge_memory.c
> +++ b/mm/huge_memory.c
> @@ -2966,6 +2966,8 @@ int move_pages_huge_pmd(struct mm_struct *mm, pmd_t *dst_pmd, pmd_t *src_pmd, pm
>  
>  		folio_move_anon_rmap(src_folio, dst_vma);
>  		src_folio->index = linear_anon_page_index(dst_vma, dst_addr);
> +		/* No rmap add, and the two VMAs need not agree on the flag. */
> +		crash_mark_pages(&src_folio->page, HPAGE_PMD_NR, dst_vma);
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
How are stale crash_memaction marks handled when moving to an unmarked VMA?

If a process marks a VMA with MADV_CRASH_CACHE, then moves an exclusive
anonymous page to an unmarked VMA via mremap() here in
move_pages_huge_pmd(), the destination VMA is checked but the source VMA
is not unmarked.

Because the new VMA lacks the mark, a subsequent madvise(MADV_CRASH_RESET)
will short-circuit and fail to unmark the pages. Will these pages remain
permanently marked and excluded from kdump dumps until freed, potentially
risking data loss?

>  
>  		_dst_pmd = folio_mk_pmd(src_folio, dst_vma->vm_page_prot);
>  		/* Follow mremap() behavior and treat the entry dirty after the move */
[ ... ]
> diff --git a/mm/userfaultfd.c b/mm/userfaultfd.c
> index b242fa8b22c8c..bb0a35d59daa9 100644
> --- a/mm/userfaultfd.c
> +++ b/mm/userfaultfd.c
> @@ -1326,6 +1326,7 @@ static long move_present_ptes(struct mm_struct *mm,
>  
>  		folio_move_anon_rmap(src_folio, dst_vma);
>  		src_folio->index = linear_anon_page_index(dst_vma, dst_addr);
> +		crash_mark_pages(&src_folio->page, 1, dst_vma);
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

[Severity: Medium]
Similar to the mremap() case above, does move_present_ptes() fail to unmark
the PFN if the page came from a marked src_vma but is moving to an unmarked
dst_vma?

[Severity: Medium]
Are we missing crash_memaction registration for swap cache folios during
UFFDIO_MOVE?

While the rmap is updated for present PTEs with a crash_mark_pages() call
here, the parallel move_swap_pte() path in mm/userfaultfd.c seems to
omit it:

	if (src_folio) {
		folio_move_anon_rmap(src_folio, dst_vma);
		src_folio->index = linear_anon_page_index(dst_vma, dst_addr);
	} else {

If a process marks a VMA with MADV_CRASH_SECRET, and then uses UFFDIO_MOVE
to move a swapped-out but swapcache-resident page into this VMA, the page
registration is skipped. If the system crashes before the page is faulted
in, is there a risk that the kdump kernel will dump the unmarked RAM and
leak the secret data?

>  
>  		orig_dst_pte = folio_mk_pte(src_folio, dst_vma->vm_page_prot);
>  		/* Set soft dirty bit so userspace can notice the pte was moved */

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=9

[PATCH v3 10/12] mm/madvise: Add MADV_CRASH_SECRET, MADV_CRASH_CACHE and MADV_CRASH_RESET

[Jan Sebastian Götte]

These flags allow userspace to indicate memory pages to a kdump kernel
that contain sensitive secrets or unimportant cache data. This allows
the kdump kernel to e.g. wipe secrets before dumping, or to skip caches
while dumping.

The feature is similar to MADV_DONTDUMP but for the kdump kernel. In
contrast to MADV_DONTDUMP, it specifies the contents of the page, not
what should be done with it. This is to account for some flexibility
between the host userspace registering the marks, and the kdump
userspace processing them.

The flags set here are matched against a mask given through the
crash_memaction= cmdline param. Only when the param is present and the
mask matches, a VMA flag ("cm") is set. The kdump kernel later receives
a single bitmap describing all marked ranges matching the mask.

When madvise'd, marked ranges are registered in the bitmap right away.
These registrations are then kept up to date by code in rmap.
Marks are transparent to swap etc.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 include/uapi/asm-generic/mman-common.h |   4 +
 mm/madvise.c                           | 132 +++++++++++++++++++++++++++++++++
 2 files changed, 136 insertions(+)

diff --git a/include/uapi/asm-generic/mman-common.h b/include/uapi/asm-generic/mman-common.h
index ef1c27fa3c57..b00caec7c130 100644
--- a/include/uapi/asm-generic/mman-common.h
+++ b/include/uapi/asm-generic/mman-common.h
@@ -79,6 +79,10 @@
 
 #define MADV_COLLAPSE	25		/* Synchronous hugepage collapse */
 
+#define MADV_CRASH_SECRET 26		/* holds secrets, tell the kdump kernel */
+#define MADV_CRASH_CACHE 27		/* holds nothing worth dumping */
+#define MADV_CRASH_RESET 28		/* undo MADV_CRASH_SECRET and MADV_CRASH_CACHE */
+
 #define MADV_GUARD_INSTALL 102		/* fatal signal on access to range */
 #define MADV_GUARD_REMOVE 103		/* unguard range */
 
diff --git a/mm/madvise.c b/mm/madvise.c
index 00b1be655a8b..37f08334e95a 100644
--- a/mm/madvise.c
+++ b/mm/madvise.c
@@ -13,6 +13,8 @@
 #include <linux/page-isolation.h>
 #include <linux/page_idle.h>
 #include <linux/userfaultfd_k.h>
+#include <linux/crash_memaction.h>
+#include <linux/rmap.h>
 #include <linux/hugetlb.h>
 #include <linux/falloc.h>
 #include <linux/fadvise.h>
@@ -1173,6 +1175,98 @@ static long madvise_populate(struct madvise_behavior *madv_behavior)
 	return 0;
 }
 
+#ifdef CONFIG_CRASH_MEMACTION
+static void madvise_crash_mark_pfns(struct mm_walk *walk, unsigned long pfn,
+		unsigned long nr_pages)
+{
+	bool mark = *(bool *)walk->private;
+
+	/* Acting on the zero page would reach every other mapping of it. */
+	if (is_zero_pfn(pfn) || is_huge_zero_pfn(pfn) || !pfn_valid(pfn))
+		return;
+
+	if (mark)
+		crash_mark_pages(pfn_to_page(pfn), nr_pages, walk->vma);
+	else
+		crash_memaction_unmark_pfns(pfn, nr_pages);
+}
+
+static int crash_mark_pmd_entry(pmd_t *pmd, unsigned long addr,
+		unsigned long end, struct mm_walk *walk)
+{
+	pte_t *start_pte, *pte;
+	spinlock_t *ptl;
+
+	if (fatal_signal_pending(current))
+		return -EINTR;
+
+	ptl = pmd_trans_huge_lock(pmd, walk->vma);
+	if (ptl) {
+		pmd_t pmdval = *pmd;
+
+		if (pmd_present(pmdval))
+			madvise_crash_mark_pfns(walk,
+				pmd_pfn(pmdval) + ((addr & ~PMD_MASK) >> PAGE_SHIFT),
+				(end - addr) >> PAGE_SHIFT);
+		spin_unlock(ptl);
+		return 0;
+	}
+
+	start_pte = pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
+	if (!start_pte)
+		return 0;
+
+	for (; addr < end; pte++, addr += PAGE_SIZE) {
+		pte_t ptent = ptep_get(pte);
+
+		if (pte_present(ptent))
+			madvise_crash_mark_pfns(walk, pte_pfn(ptent), 1);
+	}
+
+	pte_unmap_unlock(start_pte, ptl);
+	cond_resched();
+	return 0;
+}
+
+#ifdef CONFIG_HUGETLB_PAGE
+static int crash_mark_hugetlb_entry(pte_t *pte, unsigned long hmask,
+		unsigned long addr, unsigned long end, struct mm_walk *walk)
+{
+	struct hstate *h = hstate_vma(walk->vma);
+	spinlock_t *ptl;
+	pte_t entry;
+
+	ptl = huge_pte_lock(h, walk->mm, pte);
+	entry = huge_ptep_get(walk->mm, addr, pte);
+	if (pte_present(entry))
+		madvise_crash_mark_pfns(walk,
+			pte_pfn(entry) + ((addr & ~hmask) >> PAGE_SHIFT),
+			(end - addr) >> PAGE_SHIFT);
+	spin_unlock(ptl);
+
+	return 0;
+}
+#endif /* CONFIG_HUGETLB_PAGE */
+
+static const struct mm_walk_ops crash_mark_walk_ops = {
+	.pmd_entry	= crash_mark_pmd_entry,
+#ifdef CONFIG_HUGETLB_PAGE
+	.hugetlb_entry	= crash_mark_hugetlb_entry,
+#endif
+	.walk_lock	= PGWALK_WRLOCK,
+};
+
+static int madvise_crash_mark_existing(struct vm_area_struct *vma,
+		unsigned long start, unsigned long end, bool mark)
+{
+	if (!static_branch_unlikely(&crash_memaction_active))
+		return 0;
+
+	return walk_page_range_vma(vma, start, end, &crash_mark_walk_ops,
+				   &mark);
+}
+#endif /* CONFIG_CRASH_MEMACTION */
+
 /*
  * Application wants to free up the pages and associated backing store.
  * This is effectively punching a hole into the middle of a file.
@@ -1585,6 +1679,26 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior)
 	case MADV_DONTDUMP:
 		new_flags |= VM_DONTDUMP;
 		break;
+#ifdef CONFIG_CRASH_MEMACTION
+	case MADV_CRASH_SECRET:
+		if (!vma_is_anonymous(vma) && !vma_is_shmem(vma) &&
+		    !vma_is_hugetlb(vma))
+			return -EINVAL;
+		if (crash_memaction_types() & CRASH_MEMACTION_SECRET)
+			new_flags |= VM_CRASH_MARK;
+		break;
+	case MADV_CRASH_CACHE:
+		if (!vma_is_anonymous(vma) && !vma_is_shmem(vma) &&
+		    !vma_is_hugetlb(vma))
+			return -EINVAL;
+		if (crash_memaction_types() & CRASH_MEMACTION_CACHE)
+			new_flags |= VM_CRASH_MARK;
+		break;
+	case MADV_CRASH_RESET:
+		/* Unmarking stays allowed whatever the VMA has become since. */
+		new_flags &= ~VM_CRASH_MARK;
+		break;
+#endif
 	case MADV_DODUMP:
 		/* Non-persistent memory cannot be dumped. */
 		if (!vma_is_persistent(vma))
@@ -1614,6 +1728,19 @@ static int madvise_vma_behavior(struct madvise_behavior *madv_behavior)
 	/* This is a write operation.*/
 	VM_WARN_ON_ONCE(madv_behavior->lock_mode != MADVISE_MMAP_WRITE_LOCK);
 
+#ifdef CONFIG_CRASH_MEMACTION
+	/* The rmap hooks only see the flag as folios arrive, so walk the rest. */
+	if ((new_flags ^ vma->vm_flags) & VM_CRASH_MARK) {
+		error = madvise_update_vma(new_flags, madv_behavior);
+		if (!error)
+			error = madvise_crash_mark_existing(
+					madv_behavior->vma, range->start,
+					range->end,
+					!!(new_flags & VM_CRASH_MARK));
+		goto out;
+	}
+#endif
+
 	error = madvise_update_vma(new_flags, madv_behavior);
 out:
 	/*
@@ -1732,6 +1859,11 @@ madvise_behavior_valid(int behavior)
 	case MADV_KEEPONFORK:
 	case MADV_GUARD_INSTALL:
 	case MADV_GUARD_REMOVE:
+#ifdef CONFIG_CRASH_MEMACTION
+	case MADV_CRASH_SECRET:
+	case MADV_CRASH_CACHE:
+	case MADV_CRASH_RESET:
+#endif
 #ifdef CONFIG_MEMORY_FAILURE
 	case MADV_SOFT_OFFLINE:
 	case MADV_HWPOISON:

-- 
2.55.0

Re: [PATCH v3 10/12] mm/madvise: Add MADV_CRASH_SECRET, MADV_CRASH_CACHE and MADV_CRASH_RESET

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [High] mm: MADV_CRASH_SECRET skips migration entries leaving secrets unprotected
--

commit bd54b0316a2281079a7116bef1937bfde7198adf
Author: Jan Sebastian Götte <linux@jaseg.de>

mm/madvise: Add MADV_CRASH_SECRET, MADV_CRASH_CACHE and MADV_CRASH_RESET

This commit introduces new madvise flags allowing userspace to mark pages
containing secrets or unimportant cache data. These marks are registered in a
bitmap for the kdump kernel to process during a crash dump.

> diff --git a/mm/madvise.c b/mm/madvise.c
> index 00b1be655a8b5..37f08334e95a8 100644
> --- a/mm/madvise.c
> +++ b/mm/madvise.c
[ ... ]
> @@ -1173,6 +1175,98 @@ static long madvise_populate(struct madvise_behavior *madv_behavior)
[ ... ]
> +static int crash_mark_pmd_entry(pmd_t *pmd, unsigned long addr,
> +		unsigned long end, struct mm_walk *walk)
> +{
> +	pte_t *start_pte, *pte;
> +	spinlock_t *ptl;
> +
> +	if (fatal_signal_pending(current))
> +		return -EINTR;
> +
> +	ptl = pmd_trans_huge_lock(pmd, walk->vma);
> +	if (ptl) {
> +		pmd_t pmdval = *pmd;
> +
> +		if (pmd_present(pmdval))
> +			madvise_crash_mark_pfns(walk,
> +				pmd_pfn(pmdval) + ((addr & ~PMD_MASK) >> PAGE_SHIFT),
> +				(end - addr) >> PAGE_SHIFT);
> +		spin_unlock(ptl);
> +		return 0;
> +	}

[Severity: High]
Does this code leave secrets unprotected if a migration is occurring
concurrently?

If a PMD is temporarily unmapped during a migration (such as background
compaction or NUMA balancing), pmd_present evaluates to false. This
code skips the PMD without marking it and returns 0, leaving the entire
2MB range unprotected in the crash memaction bitmap. Once the migration
completes, the restored page remains permanently unmarked and will be
dumped.

> +
> +	start_pte = pte = pte_offset_map_lock(walk->mm, pmd, addr, &ptl);
> +	if (!start_pte)
> +		return 0;
> +
> +	for (; addr < end; pte++, addr += PAGE_SIZE) {
> +		pte_t ptent = ptep_get(pte);
> +
> +		if (pte_present(ptent))
> +			madvise_crash_mark_pfns(walk, pte_pfn(ptent), 1);
> +	}

[Severity: High]
Similarly, does this loop silently skip non-present PTEs like migration
and device-exclusive swap entries?

When userspace calls madvise with MADV_CRASH_SECRET, it expects the
memory range to be marked. Checking only pte_present skips resident
physical pages that are temporarily unmapped for migration. Since the
rmap hooks only see the flags as folios arrive, these skipped entries
never get added to the bitmap, potentially leaking sensitive data in a
crash dump.

> +
> +	pte_unmap_unlock(start_pte, ptl);
> +	cond_resched();
> +	return 0;
> +}
[ ... ]

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=10

[PATCH v3 11/12] Documentation/mm: Document the crash memaction registry

[Jan Sebastian Götte]

Describe the crash memaction registry, including its kernel and userspace
interfaces, allocation lifetime rules, and current limitations.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
---
 Documentation/mm/crash_memaction.rst | 59 ++++++++++++++++++++++++++++++++++++
 Documentation/mm/index.rst           |  1 +
 MAINTAINERS                          |  1 +
 3 files changed, 61 insertions(+)

diff --git a/Documentation/mm/crash_memaction.rst b/Documentation/mm/crash_memaction.rst
new file mode 100644
index 000000000000..3658bff7693c
--- /dev/null
+++ b/Documentation/mm/crash_memaction.rst
@@ -0,0 +1,59 @@
+.. SPDX-License-Identifier: GPL-2.0
+
+====================
+Crash memory actions
+====================
+
+`CONFIG_CRASH_MEMACTION` provides a mechanism for the running kernel to
+communicate a single bit attribute per memory page to a kdump kernel. This
+feature can be used by the kdump kernel to exclude certain pages (e.g. holding
+crypto secrets, or cache) from the system memory dump, or to wipe their contents
+after a  crash.
+
+The meaning of the registry bitmap is set by the ``crash_memaction=`` kernel
+cmdline parameter. The running kernel only sets the bits for the tracked pages,
+and it's up to the kdump kernel to do something with them.
+
+	``crash_memaction={secret|cache}``
+
+Right now, ``secret`` tracks pages containing kernel crypto keys as well as
+pages explicitly marked using ``madvise(2)``. ``cache`` currently only tracks
+pages marked from userspace using ``madvise(2)``.
+
+Kernel users
+============
+
+Kernel code can mark a virtual range in the linear map or in vmalloc space::
+
+	void crash_memaction_mark(void *addr, size_t size, int types);
+	void crash_memaction_unmark(void *addr, size_t size);
+
+Marking is safe from any context and cannot fail. Markings last until the page
+frame is handed out to another user to cover stale data left over after the page
+is free'd.
+
+For objects smaller than a page, lib/secret_pool provides allocations from a
+"secret" marked kmem_buckets. Objects can be allocated through secret_pool
+without the need for any additional lifetime/marking tracking.
+
+Userspace interface
+===================
+
+For userspace code, ``MADV_CRASH_SECRET``, ``MADV_CRASH_CACHE`` and
+``MADV_CRASH_RESET`` are provided for use with ``madvise(2)``. Marks show up in
+``/proc/pid/smaps`` as ``cm`` VMA flag. Only anonymous, shmem and hugetlb ranges
+can be marked. Marking is transparent to swapping and lazy allocation.
+
+Limitations
+===========
+
+* This mechanism is best-effort. During a crash, nothing can be guaranteed. At
+  page level granularity, some over- or under-marking is to be expected.
+* Marks are tracked only for *mapped* folios, so a shmem file only ever written
+  with ``write(2)`` cannot be covered.
+* A single ``madvise(2)`` call on a folio mapped into several processes globally
+  (un)marks it for all of them.
+* Marks are tracked at page level granularity. There is no refcounting. When
+  trying to mark smaller objects, use lib/secret_pool or a similar mechanism.
+* Memory hotplug is not supported at this time. When memory is hotplugged, the
+  newly hotplugged memory will not be included in the bitmap.
diff --git a/Documentation/mm/index.rst b/Documentation/mm/index.rst
index 13a79f5d092c..4cdfc5030a56 100644
--- a/Documentation/mm/index.rst
+++ b/Documentation/mm/index.rst
@@ -54,6 +54,7 @@ documentation, or deleted if it has served its purpose.
    allocation-profiling
    arch_pgtable_helpers
    balance
+   crash_memaction
    damon/index
    free_page_reporting
    hmm
diff --git a/MAINTAINERS b/MAINTAINERS
index bcb11c2138bc..269b8be6c222 100644
--- a/MAINTAINERS
+++ b/MAINTAINERS
@@ -14256,6 +14256,7 @@ L:	kexec@lists.infradead.org
 S:	Maintained
 T:	git git://git.kernel.org/pub/scm/linux/kernel/git/liveupdate/linux.git
 F:	Documentation/admin-guide/kdump/
+F:	Documentation/mm/crash_memaction.rst
 F:	fs/proc/vmcore.c
 F:	include/linux/crash_core.h
 F:	include/linux/crash_dump.h

-- 
2.55.0

Re: [PATCH v3 11/12] Documentation/mm: Document the crash memaction registry

[sashiko-bot]

> Describe the crash memaction registry, including its kernel and userspace
> interfaces, allocation lifetime rules, and current limitations.
> 
> Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>

Sashiko has reviewed this patch and found no issues. It looks great!

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=11

[PATCH v3 12/12] kexec: Expose the crash memaction bitmap in debugfs

[Jan Sebastian Götte]

Add two files under /sys/kernel/debug/crash_memaction/. "regions" lists
the physical ranges the bits describe and their offset and length in the
bitmap. "bitmap" shows the raw bits as a single blob with all ranges
concatenated. The files are root only and behind
CONFIG_CRASH_MEMACTION_DEBUGFS.

Signed-off-by: Jan Sebastian Götte <linux@jaseg.de>
Assisted-by: Claude Opus 5 <noreply@anthropic.com>
---
 Documentation/mm/crash_memaction.rst |  9 ++++++
 kernel/Kconfig.kexec                 | 14 +++++++++
 kernel/crash_core.c                  | 59 ++++++++++++++++++++++++++++++++++++
 3 files changed, 82 insertions(+)

diff --git a/Documentation/mm/crash_memaction.rst b/Documentation/mm/crash_memaction.rst
index 3658bff7693c..eacda046477e 100644
--- a/Documentation/mm/crash_memaction.rst
+++ b/Documentation/mm/crash_memaction.rst
@@ -57,3 +57,12 @@ Limitations
   trying to mark smaller objects, use lib/secret_pool or a similar mechanism.
 * Memory hotplug is not supported at this time. When memory is hotplugged, the
   newly hotplugged memory will not be included in the bitmap.
+
+Inspecting the bitmap
+=====================
+
+With ``CONFIG_CRASH_MEMACTION_DEBUGFS`` the bitmap can be read through debugfs::
+
+	# types 0x3000 page_shift 12 nr_regions 1
+	# start_pfn nr_pages offset bytes paddr
+	0x0000000000000001 0x0000000000800000 0x0 0x100000 0x0000000040000000
diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
index 3cdc8d459ac0..b5380e16bfaf 100644
--- a/kernel/Kconfig.kexec
+++ b/kernel/Kconfig.kexec
@@ -204,4 +204,18 @@ config CRASH_MEMACTION
 
 	  If unsure, say N.
 
+config CRASH_MEMACTION_DEBUGFS
+	bool "Expose the crash memaction bitmap in debugfs"
+	depends on CRASH_MEMACTION && DEBUG_FS
+	help
+	  Allow reading the live crash_memaction bitmap through
+      /sys/kernel/debug/crash_memaction/. The bitmap is used when
+      CRASH_MEMACTION is set and when a crash_memaction cmdline param is present
+      to tell an eventual kdump kernel about the use of certain memory pages.
+
+      Note that this is a debug interface only that gives no guarantees
+      whatsoever on memory consistency.
+
+	  If unsure, say N.
+
 endmenu
diff --git a/kernel/crash_core.c b/kernel/crash_core.c
index 6bb2f5645ca6..5eb5a5ada8e0 100644
--- a/kernel/crash_core.c
+++ b/kernel/crash_core.c
@@ -28,9 +28,11 @@
 #include <linux/atomic.h>
 #include <linux/bitmap.h>
 #include <linux/bitops.h>
+#include <linux/debugfs.h>
 #include <linux/jump_label.h>
 #include <linux/overflow.h>
 #include <linux/pfn.h>
+#include <linux/seq_file.h>
 #include <linux/slab.h>
 #include <linux/string.h>
 #include <linux/sysfs.h>
@@ -66,6 +68,10 @@ static struct crash_memaction_region *crash_memaction_regions __ro_after_init;
 static unsigned int crash_memaction_nr_regions __ro_after_init;
 static size_t crash_memaction_note_bytes __ro_after_init;
 
+/* The one allocation all of the bitmaps above were carved out of. */
+static void *crash_ma_bitmap_base __ro_after_init;
+static size_t crash_ma_bitmap_size __ro_after_init;
+
 static struct crash_memaction_note *crash_memaction_desc __ro_after_init;
 static size_t crash_memaction_desc_bytes __ro_after_init;
 
@@ -148,6 +154,8 @@ void __init crash_memaction_init(void)
 	if (!bits)
 		goto nomem;
 
+	crash_ma_bitmap_base = bits;
+	crash_ma_bitmap_size = total_bytes;
 	for (i = 0; i < nr; i++) {
 		regions[i].bits = bits;
 		bits += bitmap_size(regions[i].nr_pages);
@@ -341,6 +349,57 @@ void crash_memaction_unmark(void *addr, size_t size)
 }
 EXPORT_SYMBOL_GPL(crash_memaction_unmark);
 
+#ifdef CONFIG_CRASH_MEMACTION_DEBUGFS
+
+static struct debugfs_blob_wrapper crash_ma_bitmap_blob;
+
+/* @paddr is what the note gives, so a vmcore can be matched to a live one. */
+static int crash_memaction_regions_show(struct seq_file *m, void *v)
+{
+	unsigned long offset = 0;
+	unsigned int i;
+
+	seq_printf(m, "# types 0x%x page_shift %u nr_regions %u\n",
+		   crash_memaction_type_mask, PAGE_SHIFT,
+		   crash_memaction_nr_regions);
+	seq_puts(m, "# start_pfn nr_pages offset bytes paddr\n");
+
+	for (i = 0; i < crash_memaction_nr_regions; i++) {
+		struct crash_memaction_region *reg = &crash_memaction_regions[i];
+		size_t bytes = bitmap_size(reg->nr_pages);
+		phys_addr_t paddr = __pa(reg->bits);
+
+		seq_printf(m, "0x%016lx 0x%016lx 0x%016lx 0x%016zx %pa\n",
+			   reg->start_pfn, reg->nr_pages, offset, bytes, &paddr);
+		offset += bytes;
+	}
+
+	return 0;
+}
+DEFINE_SHOW_ATTRIBUTE(crash_memaction_regions);
+
+static int __init crash_memaction_debugfs_init(void)
+{
+	struct dentry *dir;
+
+	if (!crash_memaction_nr_regions)
+		return 0;
+
+	dir = debugfs_create_dir("crash_memaction", NULL);
+
+	debugfs_create_file("regions", 0400, dir, NULL,
+			    &crash_memaction_regions_fops);
+
+	crash_ma_bitmap_blob.data = crash_ma_bitmap_base;
+	crash_ma_bitmap_blob.size = crash_ma_bitmap_size;
+	debugfs_create_blob("bitmap", 0400, dir, &crash_ma_bitmap_blob);
+
+	return 0;
+}
+fs_initcall(crash_memaction_debugfs_init);
+
+#endif /* CONFIG_CRASH_MEMACTION_DEBUGFS */
+
 int crash_load_memaction(struct kimage *image)
 {
 	unsigned long nr_pages, i;

-- 
2.55.0

Re: [PATCH v3 12/12] kexec: Expose the crash memaction bitmap in debugfs

[sashiko-bot]

Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Low] kconfig: syntax error due to insufficient indentation in help text
--

commit d0f9200d03ebaf0ef39b9f78a15ab259102ed7e8
Author: Jan Sebastian Götte <linux@jaseg.de>

kexec: Expose the crash memaction bitmap in debugfs

This commit adds debugfs support to expose the crash memaction bitmap by
creating "regions" and "bitmap" files under /sys/kernel/debug/crash_memaction/.
The feature is guarded by the new CONFIG_CRASH_MEMACTION_DEBUGFS option.

> diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
> index 3cdc8d459ac05..b5380e16bfafb 100644
> --- a/kernel/Kconfig.kexec
> +++ b/kernel/Kconfig.kexec
> @@ -204,4 +204,18 @@ config CRASH_MEMACTION

[ ... ]

> +config CRASH_MEMACTION_DEBUGFS
> +	bool "Expose the crash memaction bitmap in debugfs"
> +	depends on CRASH_MEMACTION && DEBUG_FS
> +	help
> +	  Allow reading the live crash_memaction bitmap through
> +      /sys/kernel/debug/crash_memaction/. The bitmap is used when

[Severity: Low]
Does this indentation break the Kconfig help block?

The first line of the help text is indented with 1 tab and 2 spaces (which
is equivalent to 10 spaces in Kconfig), but this line starts with only 6
spaces. The Kconfig lexer terminates a help block when it encounters an
indentation level lower than the block's first line. This could cause the
parser to interpret the rest of the text as an invalid Kconfig directive,
potentially resulting in a syntax error and build failure during make config.

> +      CRASH_MEMACTION is set and when a crash_memaction cmdline param is present
> +      to tell an eventual kdump kernel about the use of certain memory pages.
> +
> +      Note that this is a debug interface only that gives no guarantees
> +      whatsoever on memory consistency.
> +
> +	  If unsure, say N.
> +
>  endmenu

-- 
Sashiko AI review · https://sashiko.dev/#/patchset/20260928-crash-memaction-upstream-20260921-v3-0-e511e9ee2329@jaseg.de?part=12

Re: [PATCH v3 12/12] kexec: Expose the crash memaction bitmap in debugfs

[Randy Dunlap]

On 9/28/26 10:18 AM, Jan Sebastian Götte wrote:
> diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
> index 3cdc8d459ac0..b5380e16bfaf 100644
> --- a/kernel/Kconfig.kexec
> +++ b/kernel/Kconfig.kexec
> @@ -204,4 +204,18 @@ config CRASH_MEMACTION
>  
>  	  If unsure, say N.
>  
> +config CRASH_MEMACTION_DEBUGFS
> +	bool "Expose the crash memaction bitmap in debugfs"
> +	depends on CRASH_MEMACTION && DEBUG_FS
> +	help
> +	  Allow reading the live crash_memaction bitmap through
> +      /sys/kernel/debug/crash_memaction/. The bitmap is used when
> +      CRASH_MEMACTION is set and when a crash_memaction cmdline param is present
> +      to tell an eventual kdump kernel about the use of certain memory pages.
> +
> +      Note that this is a debug interface only that gives no guarantees
> +      whatsoever on memory consistency.
> +
> +	  If unsure, say N.
> +
>  endmenu

Please adhere to kernel coding style for Kconfig files:

10) Kconfig configuration files
-------------------------------

For all of the Kconfig* configuration files throughout the source tree,
the indentation is somewhat different.  Lines under a ``config`` definition
are indented with one tab, while help text is indented an additional two
spaces.

-- 
~Randy

Re: [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)

[Lorenzo Stoakes (ARM)]

On Mon, Sep 28, 2026 at 07:17:48PM +0200, Jan Sebastian Götte wrote:
> 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.

Sorry this all seems really invasive for what seems to be a very specific
use case.

In general, with big changes like this, you should send the series as an
RFC.

Please send any future revisions of this as an RFC.

The bar for a new VMA flag, a new madvise() flag, etc. is really quite
high, and I've already noticed what looks like quite buggy code glancing
through.

And again, I really don't think your case sounds all that compelling for
general users, given how invasive the changes are, so I strongly suggest
you rethink your approach.

In any case, as a newcomer to mm, we really ask that people start with
smaller changes and build up gradually, a change like this really should
only be done by somebody with an established reputation in the kernel.

In general re: AI-generated code see
https://docs.kernel.org/process/generated-content.html

	If tools permit you to generate a contribution automatically, expect
	additional scrutiny in proportion to how much of it was generated.

	As with the output of any tooling, the result may be incorrect or
	inappropriate. You are expected to understand and to be able to defend
	everything you submit. If you are unable to do so, then do not submit the
	resulting changes.

	If you do so anyway, maintainers are entitled to reject your series without
	detailed review.

Thanks!

--
Cheers, Lorenzo

Re: [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)

[David Hildenbrand (Arm)]

On 9/28/26 19:49, Lorenzo Stoakes (ARM) wrote:
> On Mon, Sep 28, 2026 at 07:17:48PM +0200, Jan Sebastian Götte wrote:
>> 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.
> 
> Sorry this all seems really invasive for what seems to be a very specific
> use case.
> 
> In general, with big changes like this, you should send the series as an
> RFC.
> 
> Please send any future revisions of this as an RFC.
> 
> The bar for a new VMA flag, a new madvise() flag, 

It's actually three new madvise modes. Way to invasive indeed. This won't fly.

-- 
Cheers,

David

Re: [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)

[David Hildenbrand (Arm)]

On 9/28/26 19:17, Jan Sebastian Götte wrote:
> 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.

This is all rather messy.

So, in general, kdump has access to the memmap, and it can figure out certain
things about pages to be dumped. That's what makedumpfile does.

It can identify user pages, kernel pages, etc. If you could identify relevant
pages through the memmap from the second kernel, you might be able to clean them.

I'd assume you could identify secretmem pages that way.

But all these madvise/mmap thingies are really not appropriate to reduce the
zeroing.

-- 
Cheers,

David