From: "David Hildenbrand (Arm)" <david@kernel.org>
To: "Lorenzo Stoakes (ARM)" <ljs@kernel.org>,
"Jan Sebastian Götte" <linux@jaseg.de>
Cc: Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Rob Herring <robh@kernel.org>,
Saravana Kannan <saravanak@kernel.org>,
Andrew Morton <akpm@linux-foundation.org>,
Baoquan He <baoquan.he@linux.dev>,
Mike Rapoport <rppt@kernel.org>,
Pasha Tatashin <pasha.tatashin@soleen.com>,
Pratyush Yadav <pratyush@kernel.org>,
Dave Young <ruirui.yang@linux.dev>,
Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
"Rafael J. Wysocki" <rafael@kernel.org>,
Danilo Krummrich <dakr@kernel.org>,
Muchun Song <muchun.song@linux.dev>,
Oscar Salvador <osalvador@suse.de>,
Vlastimil Babka <vbabka@kernel.org>,
Suren Baghdasaryan <surenb@google.com>,
Michal Hocko <mhocko@suse.com>,
Brendan Jackman <brendan.jackman@linux.dev>,
Johannes Weiner <hannes@cmpxchg.org>, Zi Yan <ziy@nvidia.com>,
Catalin Marinas <catalin.marinas@arm.com>,
Will Deacon <will@kernel.org>,
Mark Rutland <mark.rutland@arm.com>,
Alasdair Kergon <agk@redhat.com>,
Mike Snitzer <snitzer@kernel.org>,
Mikulas Patocka <mpatocka@redhat.com>,
Benjamin Marzinski <bmarzins@redhat.com>,
Herbert Xu <herbert@gondor.apana.org.au>,
"David S. Miller" <davem@davemloft.net>,
Mimi Zohar <zohar@linux.ibm.com>,
David Howells <dhowells@redhat.com>,
Jarkko Sakkinen <jarkko@kernel.org>,
Paul Moore <paul@paul-moore.com>,
James Morris <jmorris@namei.org>,
"Serge E. Hallyn" <serge@hallyn.com>,
James Bottomley <James.Bottomley@hansenpartnership.com>,
"Liam R. Howlett" <liam@infradead.org>,
Jann Horn <jannh@google.com>, Pedro Falcato <pfalcato@suse.de>,
Rik van Riel <riel@surriel.com>, Harry Yoo <harry@kernel.org>,
Lance Yang <lance.yang@linux.dev>,
Baolin Wang <baolin.wang@linux.alibaba.com>,
Nico Pache <nico.pache@linux.dev>,
Ryan Roberts <ryan.roberts@arm.com>, Dev Jain <dev.jain@arm.com>,
Barry Song <baohua@kernel.org>, Usama Arif <usama.arif@linux.dev>,
Kiryl Shutsemau <kas@kernel.org>,
Matthew Brost <matthew.brost@intel.com>,
Joshua Hahn <joshua.hahnjy@gmail.com>,
Byungchul Park <byungchul@sk.com>,
Gregory Price <gourry@gourry.net>,
Ying Huang <ying.huang@linux.alibaba.com>,
Alistair Popple <apopple@nvidia.com>,
Peter Xu <peterx@redhat.com>, Arnd Bergmann <arnd@arndb.de>,
Eric Biggers <ebiggers@kernel.org>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
devicetree@vger.kernel.org, kexec@lists.infradead.org,
driver-core@lists.linux.dev, linux-mm@kvack.org,
linux-arm-kernel@lists.infradead.org, dm-devel@lists.linux.dev,
linux-crypto@vger.kernel.org, linux-integrity@vger.kernel.org,
keyrings@vger.kernel.org, linux-security-module@vger.kernel.org,
linux-fsdevel@vger.kernel.org, linux-arch@vger.kernel.org
Subject: Re: [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS)
Date: Mon, 28 Sep 2026 20:58:22 +0200 [thread overview]
Message-ID: <9d4517d0-0e78-4eee-970e-0cac9d0a856f@kernel.org> (raw)
In-Reply-To: <arqli0H0v5qPG22z@gremlin>
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
next prev parent reply other threads:[~2026-09-28 18:58 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-28 17:17 [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS) Jan Sebastian Götte
2026-09-28 17:17 ` [PATCH v3 01/12] kexec: Add a crash memaction registry Jan Sebastian Götte
2026-09-28 17:36 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 02/12] lib, kexec: Add a secret pool for key material Jan Sebastian Götte
2026-09-28 17:36 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 03/12] mm: Wire up the crash memaction registry Jan Sebastian Götte
2026-09-28 17:38 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 04/12] arm64: Enable " Jan Sebastian Götte
2026-09-28 17:35 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 05/12] dm crypt: Allocate key material from the secret pool Jan Sebastian Götte
2026-09-28 17:33 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 06/12] crypto: api - Allocate tfms " Jan Sebastian Götte
2026-09-28 17:32 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 07/12] security/keys: Allocate key payloads " Jan Sebastian Götte
2026-09-28 17:32 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 08/12] mm: Add VM_CRASH_MARK Jan Sebastian Götte
2026-09-28 17:34 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 09/12] mm/rmap: Mark folios mapped into crash_memaction-marked VMAs Jan Sebastian Götte
2026-09-28 17:41 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 10/12] mm/madvise: Add MADV_CRASH_SECRET, MADV_CRASH_CACHE and MADV_CRASH_RESET Jan Sebastian Götte
2026-09-28 17:35 ` sashiko-bot
2026-09-28 17:17 ` [PATCH v3 11/12] Documentation/mm: Document the crash memaction registry Jan Sebastian Götte
2026-09-28 17:31 ` sashiko-bot
2026-09-28 17:18 ` [PATCH v3 12/12] kexec: Expose the crash memaction bitmap in debugfs Jan Sebastian Götte
2026-09-28 17:38 ` sashiko-bot
2026-09-28 19:19 ` Randy Dunlap
2026-09-28 17:49 ` [PATCH v3 00/12] CRASH_MEMACTION: describe pages to a kdump kernel (was: CRASH_WIPE_SECRETS) Lorenzo Stoakes (ARM)
2026-09-28 18:58 ` David Hildenbrand (Arm) [this message]
2026-09-28 19:02 ` David Hildenbrand (Arm)
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=9d4517d0-0e78-4eee-970e-0cac9d0a856f@kernel.org \
--to=david@kernel.org \
--cc=James.Bottomley@hansenpartnership.com \
--cc=agk@redhat.com \
--cc=akpm@linux-foundation.org \
--cc=apopple@nvidia.com \
--cc=arnd@arndb.de \
--cc=baohua@kernel.org \
--cc=baolin.wang@linux.alibaba.com \
--cc=baoquan.he@linux.dev \
--cc=bmarzins@redhat.com \
--cc=brendan.jackman@linux.dev \
--cc=byungchul@sk.com \
--cc=catalin.marinas@arm.com \
--cc=corbet@lwn.net \
--cc=dakr@kernel.org \
--cc=davem@davemloft.net \
--cc=dev.jain@arm.com \
--cc=devicetree@vger.kernel.org \
--cc=dhowells@redhat.com \
--cc=dm-devel@lists.linux.dev \
--cc=driver-core@lists.linux.dev \
--cc=ebiggers@kernel.org \
--cc=gourry@gourry.net \
--cc=gregkh@linuxfoundation.org \
--cc=hannes@cmpxchg.org \
--cc=harry@kernel.org \
--cc=herbert@gondor.apana.org.au \
--cc=jannh@google.com \
--cc=jarkko@kernel.org \
--cc=jmorris@namei.org \
--cc=joshua.hahnjy@gmail.com \
--cc=kas@kernel.org \
--cc=kexec@lists.infradead.org \
--cc=keyrings@vger.kernel.org \
--cc=lance.yang@linux.dev \
--cc=liam@infradead.org \
--cc=linux-arch@vger.kernel.org \
--cc=linux-arm-kernel@lists.infradead.org \
--cc=linux-crypto@vger.kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-fsdevel@vger.kernel.org \
--cc=linux-integrity@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-mm@kvack.org \
--cc=linux-security-module@vger.kernel.org \
--cc=linux@jaseg.de \
--cc=ljs@kernel.org \
--cc=mark.rutland@arm.com \
--cc=matthew.brost@intel.com \
--cc=mhocko@suse.com \
--cc=mpatocka@redhat.com \
--cc=muchun.song@linux.dev \
--cc=nico.pache@linux.dev \
--cc=osalvador@suse.de \
--cc=pasha.tatashin@soleen.com \
--cc=paul@paul-moore.com \
--cc=peterx@redhat.com \
--cc=pfalcato@suse.de \
--cc=pratyush@kernel.org \
--cc=rafael@kernel.org \
--cc=rdunlap@infradead.org \
--cc=riel@surriel.com \
--cc=robh@kernel.org \
--cc=rppt@kernel.org \
--cc=ruirui.yang@linux.dev \
--cc=ryan.roberts@arm.com \
--cc=saravanak@kernel.org \
--cc=serge@hallyn.com \
--cc=skhan@linuxfoundation.org \
--cc=snitzer@kernel.org \
--cc=surenb@google.com \
--cc=usama.arif@linux.dev \
--cc=vbabka@kernel.org \
--cc=will@kernel.org \
--cc=ying.huang@linux.alibaba.com \
--cc=ziy@nvidia.com \
--cc=zohar@linux.ibm.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.