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: <20241217134238.475b4011@gandalf.local.home>
Date: Tue, 17 Dec 2024 13:42:38 -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 10:24:42 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, 17 Dec 2024 at 10:19, Linus Torvalds
> <torvalds@...ux-foundation.org> wrote:
> >
> > What *woiuld* have been an acceptable model is to actually modify the
> > boot-time buffers in place, using actual real heuristics that look at
> > whether a pointer was IN THE CODE SECTION OR THE STATIC DATA section
> > of the previous boot.
> >
> > But you never did that. All this delta code has always been complete
> > and utter garbage, and complete hacks.  
> 
> Actually, I think the proper model isn't even that "modify boot time
> buffers in place" thing.
> 
> The proper model was probably always to just do the "give the raw
> data, and analyze the previous boot data in user mode". Don't do
> "delta between old and new kernel", print out the actual KASLR base of
> the old kernel, and let user mode figure it out. Because user mode may
> actually have the old and different vmlinux image too - something that
> kernel mode *never* has.

I already support this somewhat, as the text_delta (and data_delta) are
presented in the tracefs directory so that trace-cmd can parse it.

For my use case, this would work, as we are extracting the raw data and
need to do most the processing in user space anyway. I could have it export
the KASLR offset of the previous boot and then trace-cmd should be able to
handle it fine if the events and kallsyms of the previous boot are all
saved. It could easily put things back together, including modules and
dynamic events.

This will just make it useless for those that want to use the tracefs
directly.

-- Steve