Re: [PATCH] pstore/ftrace: Factor KASLR offset in the core kernel instruction addresses

["Guilherme G. Piccoli" <gpiccoli@igalia.com>]

On 13/03/2026 17:28, Steven Rostedt wrote:
> [...]
> 
> You can look at what ftrace does with the persistent ring buffer. It adds
> the offset data to a "scratch pad" that is saved in the persistent memory.
> 
>   https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/trace/trace.c#n5352
> 
> If you know your memory isn't reset over reboots, you can create a
> "persistent ring buffer" via the kernel command line:
> 
>   reserve_mem=20M:2M:trace trace_instance=boot_map@trace
> 
> Read more about it here: https://docs.kernel.org/trace/debugging.html
> 
> Then on reboot, the persistent ring buffer lives here:
> 
>   /sys/kernel/tracing/instances/boot_map/
> 
> You can enable tracing just like any other instance:
> 
>   # echo 1 > /sys/kernel/tracing/instances/boot_map/tracing_on
>   # echo function_graph > /sys/kernel/tracing/instances/boot_map/current_tracer
>   # cat /sys/kernel/tracing/instances/boot_map/trace
> 
> Then reboot, if the memory wasn't corrupted or reset, the instance will
> have everything from the last boot, right to where it rebooted the machine.
> 
> There's a file that shows the indexes of the kernel from the previous boot:
> 
>   # cat /sys/kernel/tracing/instances/boot_map/last_boot_info 
> ffffffffa6000000	[kernel]
> ffffffffc0400000	drm
[...]

Hi Steve, this is very interesting! Thanks for pointing that
infrastructure. And I'm glad it confirms my impression that the full fix
of that isn't trivial heh

So, are you suggesting to use the ftrace infrastructure in the
pstore/ftrace? Well, seeing how mature the ftrace infra is with regards
the persistent ring buffer, I'd say pstore/ftrace+ramoops gets useless
now heh

The usage then for pstore/ftrace would be more with other backends,
really low memory cases like ERST or UEFI, for example, in embedded
maybe. And in this case, saving the full modules name table + offsets
could incur some precious memory consumption and/or performance impact.
Or maybe I'm talking nonsense and this would be quite OK ... guess worth
taking a look.

I'll wait a bit more to see what pstore maintainers think about that, if
is worth to have the very simple KASLR fix or a bit more engineered
solution that factors modules as well.

Thanks again,


Guilherme