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: <c320510d-c0ec-4c4c-98b5-457c193cae6d@efficios.com>
Date: Tue, 17 Dec 2024 14:22:22 -0500
From: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>
To: Linus Torvalds <torvalds@...ux-foundation.org>,
 Steven Rostedt <rostedt@...dmis.org>
Cc: linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 Masami Hiramatsu <mhiramat@...nel.org>, Mark Rutland <mark.rutland@....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 2024-12-17 13:24, Linus Torvalds 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".

It appears that you just summarized the LTTng (out-of-tree) kernel
tracer [1] model in one short sentence.

If this can help in some way, within the LTTng model, here is how
we're solving the problem of mapping addresses to symbols:

1- We have a statedump infrastructure, which dumps internal kernel
    state. It could dump the kernel and each module base addresses
    into the trace. (we do it for userspace tracing)

2- We can hook on module load/unload to insert event about insertion
    and removal of those base addresses into the trace buffers.
    (we do it for userspace tracing)

3- We augment the traces at post-processing with DWARF and ELF parsers
    in Babeltrace [2] to augment the trace with symbolic information
    using the ELF or DWARF files as inputs in addition to the traces.
    (this already exists, and is used for userspace traces)

4- We already have the integration of the LTTng Userspace tracer
    with PMEM and DAX to recover traces after a machine crash.
    Those buffers are self-described with an ABI which allows a
    userspace tool (lttng-crash) to extract well-formed Common
    Trace Format [3] traces from the buffers after reboot. We've
    never had the incentive to port this facility to the kernel
    tracer so far though.

Thanks,

Mathieu

[1] https://lttng.org
[2] https://babeltrace.org
[3] https://diamon.org/ctf

-- 
Mathieu Desnoyers
EfficiOS Inc.
https://www.efficios.com