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: <20241217133318.06f849c9@gandalf.local.home>
Date: Tue, 17 Dec 2024 13:33:18 -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:19:45 -0800
Linus Torvalds <torvalds@...ux-foundation.org> wrote:

> On Tue, 17 Dec 2024 at 10:04, Steven Rostedt <rostedt@...dmis.org> wrote:
> >
> > I'm not sure what you mean. If the kernels are the same, then the pointers
> > should also be the same, as KASLR just shifts them. This no longer uses
> > module code. It only traces core kernel code which should always have the
> > same offsets.  
> 
>  (a) the shifting is what caused problems with you having to hack
> round the format string and %pS.

How else do I get the function name?

> 
>  (b) the data addresses are more than shifted, so that "data_delta" is
> *completely* bogus

The data_delta and text_delta are equal, and I could get rid of delta_data,
as I haven't used it. I only used the text_delta as they are always the
same.

> 
>  (c) neither of them are AT ALL valid for modules regardless

I can make sure that it only works for core kernel code, and print the raw
address if it isn't.

> 
> Stop using the delta fields. They are broken. Even for the same
> kernel. It's literally a "I made sh*t up and it sometimes works"
> situation.
> 
> That "sometimes works" is not how we do kernel development. Stop it.

For core kernel code it *always works*. I haven't seen it fail yet.

This is the point of this patch series, is to remove the cases where it can
fail. That is, if the kernel isn't the same, or the use of modules and
dynamic events that are not stable across reboots.

But for the core kernel code, I have not seen it fail once!

> 
> 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.

So basically, you want a full parser of the trace event code that reads the
boot time buffer and makes it match the current kernel?

> 
> But you never did that. All this delta code has always been complete
> and utter garbage, and complete hacks.
> 
> Remove it.
> 
> Then, if at some point you can do it *right* (see above), maybe you
> can try to re-introduce it. But the current delta code is pure and
> utter garbage and needs to die. No more of this "hacking shit up to
> make it sometimes work".

As I said. It doesn't "sometimes work" it "always works", at least for the
core kernel. And I agree that it shouldn't "sometimes work" which is why
this patch series sets out to remove those cases that do not work.

-- Steve