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: <20251119133836.47d9ae73@gandalf.local.home>
Date: Wed, 19 Nov 2025 13:38:36 -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 20:24:23 +0200
Eugen Hristev <eugen.hristev@...aro.org> wrote:


> The problem is that all the meta-data is not allocated inside the
> preallocated buffer. The meta-data is kmalloced all around the code. I
> mean the structs that hold the information on what's in the buffer. You
> know what I mean.
> And all these kmalloced things, turn out to be in order of hundreds just
> on a kernel boot, which I tested. This is not feasible for the
> meminspect table, as it would get overcrowded very easily.
> I thought of perhaps trying to kmalloc all of them in a dedicated cache,
> but I haven't progressed on that. Another idea would be to try to
> recreate the meta, but I have not found a way to do it yet.>
> > 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.  
> I used 'crash' tool with trace plugin and I am able to see all the trace
> contents, but, with the limitation above. (To achieve this, I dumped a
> huge area to include it, so , not feasible for my goal )

Can't you at boot up just run:

   trace-cmd restore -c -o trace-head.dat

?

That records all the meta data of the running machine, and places it into a
trace-head.dat file. You can save that off anywhere.

Then after a crash, if you split the buffers up into individual cpu raw data
files, you can then run:

  trace-cmd restore -o trace.dat -i trace-head.dat trace-cpu0.raw trace-cpu1.raw ...

And it will create a trace.dat file for you that you can read with:

  trace-cmd report trace.dat

-- Steve