linux-kernel - Re: [PATCH 00/26] Introduce meminspect

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: <20251119131534.392277e3@gandalf.local.home>
Date: Wed, 19 Nov 2025 13:15:34 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Eugen Hristev <eugen.hristev@...aro.org>
Cc: linux-arm-msm@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, tglx@...utronix.de, andersson@...nel.org,
 pmladek@...e.com, rdunlap@...radead.org, corbet@....net, david@...hat.com,
 mhocko@...e.com, tudor.ambarus@...aro.org, mukesh.ojha@....qualcomm.com,
 linux-arm-kernel@...ts.infradead.org, linux-hardening@...r.kernel.org,
 jonechou@...gle.com, linux-doc@...r.kernel.org, devicetree@...r.kernel.org,
 linux-remoteproc@...r.kernel.org, linux-arch@...r.kernel.org,
 tony.luck@...el.com, kees@...nel.org
Subject: Re: [PATCH 00/26] Introduce meminspect

On Wed, 19 Nov 2025 17:44:01 +0200
Eugen Hristev <eugen.hristev@...aro.org> wrote:

> Once you have all the files simply use `cat` to put them all together,
> in the order of the indexes.
> For my kernel config and setup, here is my cat command : (you can use a script
> or something, I haven't done that so far):

Interesting.  Hmm, it seems this could be used with the persistent ring
buffer code as well. But if the firmware does not keep the memory around on
reboot (where the buffer would be reloaded), you could mark the persistent
ring buffer's memory to be inspected.

The persistent ring buffer creates a single allocation to hold all per-cpu
memory in a single region. That is, because on a crash and reboot, it
expects that memory to be at the same location and does a verification
check to see if it contains a valid buffer. If it does, it will recreate it
for view in the instance directory of choice.

Now if this same range is marked for inspection, you could then download
the entire contents of the persistent ring buffer after a crash. It would
be trivial to update trace-cmd's restore functionality to rebuild a
trace.dat file from it. It would require saving the event formats of the
running kernel before the crash, but that's not hard to do.

That is, by using the persistent ring buffer code with the meminspect, if
the firmware doesn't save the memory across reboots but allows you to dump
it to disk, you can enable tracing within the persistent ring buffer, on
crash, extract the buffer, and then use trace-cmd to rebuild a trace.dat
file that you can now inspect, and see the trace that lead up to the crash.

Now I don't have any hardware that uses this feature (not that I know of),
but if others find this useful, I would most definitely help them implement
it.

-- Steve