linux-kernel - Re: [PATCH 1/3] ring-buffer: Add uname to match criteria for persistent ring buffer

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: <20241217144411.2165f73b@gandalf.local.home>
Date: Tue, 17 Dec 2024 14:44:11 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: Linus Torvalds <torvalds@...ux-foundation.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org, Masami
 Hiramatsu <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....com>,
 Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Andrew Morton
 <akpm@...ux-foundation.org>, stable@...r.kernel.org
Subject: Re: [PATCH 1/3] ring-buffer: Add uname to match criteria for
 persistent ring buffer

On Tue, 17 Dec 2024 11:38:00 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, 17 Dec 2024 at 11:01, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > But instead, I'll replace the text/data_deltas with a kaslr offset (it will
> > only be exported if the trace contains data from a previous kernel so not
> > to export the current kaslr offset).  
> 
> Right - never export the KASRL offset for the *current* kernel, but
> the same interface that exports the "previous kernel trace data" can
> certainly export the KASLR for that previous case.

But this will be future work and not something for this merge window, as
it's more of a feature. The only fix is to add that print_field() code, and
the patch series that removes trace_check_vprintf() (which fixes a
different bug).

> 
> > Then, on our production systems, we'll save the meta data of the events we
> > enable (this can include module events as well as dynamic events) and after
> > a crash, we'll extract the data along with the saved data stored on disk,
> > and be able to recreate the entire trace.  
> 
> Yes. And if you save the module names and load addresses, you can now
> hopefully sort out things like %s (and %pS) from modules too.
> 
> Although maybe they don't happen that often?

Actually, they do appear a bit. As the kmalloc trace event records the call
sites that do allocation and many of them are in module code.

-- Steve