linux-hardening - Re: [RFC][PATCH v3 00/16] Introduce kmemdump

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f9e90d18-ead0-404a-937e-f5e2cf11c0f7@linaro.org>
Date: Tue, 16 Sep 2025 18:27:45 +0300
From: Eugen Hristev <eugen.hristev@...aro.org>
To: "Luck, Tony" <tony.luck@...el.com>,
 Mukesh Ojha <mukesh.ojha@....qualcomm.com>
Cc: "kees@...nel.org" <kees@...nel.org>,
 "gpiccoli@...lia.com" <gpiccoli@...lia.com>,
 "linux-arm-msm@...r.kernel.org" <linux-arm-msm@...r.kernel.org>,
 "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
 "linux-mm@...ck.org" <linux-mm@...ck.org>,
 "tglx@...utronix.de" <tglx@...utronix.de>,
 "andersson@...nel.org" <andersson@...nel.org>,
 "pmladek@...e.com" <pmladek@...e.com>,
 "rdunlap@...radead.org" <rdunlap@...radead.org>,
 "corbet@....net" <corbet@....net>, "david@...hat.com" <david@...hat.com>,
 "mhocko@...e.com" <mhocko@...e.com>,
 "tudor.ambarus@...aro.org" <tudor.ambarus@...aro.org>,
 "linux-arm-kernel@...ts.infradead.org"
 <linux-arm-kernel@...ts.infradead.org>,
 "linux-hardening@...r.kernel.org" <linux-hardening@...r.kernel.org>,
 "jonechou@...gle.com" <jonechou@...gle.com>,
 "rostedt@...dmis.org" <rostedt@...dmis.org>,
 "linux-doc@...r.kernel.org" <linux-doc@...r.kernel.org>,
 "devicetree@...r.kernel.org" <devicetree@...r.kernel.org>
Subject: Re: [RFC][PATCH v3 00/16] Introduce kmemdump



On 9/16/25 18:25, Luck, Tony wrote:
>> +Adding some pstore experts to bring this to their attention if this can
>> be followed and if they find it useful.
> 
> Depends on the capabilities of the pstore backend. Some of them
> (ERST, EFI variables) have tiny capacity (just a few kilobytes) so
> well suited for saving the tail of the console log, but if the user specified
> more than a couple of pages to be dumped using this mechanism, that
> would exceed the persistent store capacity.
> 
> -Tony

The backend can fully decide what to select from all the regions.
Some regions of interest are named (listed inside an enum with an ID),
and some have an incremental ID that is being assigned.
Either way, the backend can choose to ignore what is unwanted.
E.g. patch 16/16 where the kinfo driver selects just a few of the
regions which are of interest for Pixel debugging, the rest being ignored.