On 13/03/2026 17:00, Guilherme G. Piccoli wrote: > The pstore ftrace frontend works by purely collecting the > instruction address, saving it on the persistent area through > the backend and when the log is read, on next boot for example, > the address is then resolved by using the regular printk symbol > lookup (%pS for example). > > Problem: if we are running a relocatable kernel with KASLR enabled, > this is a recipe for failure in the symbol resolution on next boots, > since the addresses are offset'ed by the KASLR address. So, naturally > the way to go is factor the KASLR address out of instruction address > collection, and adding the fresh offset when resolving the symbol > on future boots. > > Problem #2: modules also have varying addresses that float based > on module base address and potentially the module ordering in > memory, meaning factoring KASLR offset for them is useless. > So, let's hereby only take KASLR offset into account for core > kernel addresses, leaving module ones as is. > > And we have yet a 3rd complexity: not necessarily the check range > for core kernel addresses holds true on future boots, since the > module base address will vary. With that, the choice was to mark > the addresses as being core vs module based on its MSB. And with > that... > > ...we have the 4th challenge here: for some "simple" architectures, > the CPU number is saved bit-encoded on the instruction pointer, to > allow bigger timestamps - this is set through the PSTORE_CPU_IN_IP > define for such architectures. Hence, the approach here is to skip > such architectures (at least in a first moment). > > TL;DR: let's factor KASLR offsets on pstore/ftrace for core kernel > addresses, leaving module addresses out and also leaving the > architectures that define PSTORE_CPU_IN_IP. > > Signed-off-by: Guilherme G. Piccoli <[email protected]> > --- > > > Hi folks, first of all thanks in advance for reviews and comments! > > I was testing a pstore/ftrace patch the other day and noticed > the lack of the KASLR support. But to my surprise, it was not > as easy to fix up as I expected heh > > Main reason is the obvious thing with modules: the way to > go, I think, is to somehow save the module name (or some other > id?) and the instruction offset inside such module, to then > resolve that in next boot, when printing. But that would require > more intrusive changes in the way pstore/ftrace saves the IP > (which is quite simple now), leading to some potentially > meaningful perf overhead. > > Hence, I've decided to just mess with core kernel addresses > so far, lemme know WDYT - should I somehow pursue fixing > modules addr resolution as well? Or doesn't worth the changes? > Any ideas on how to approach that? I noticed that currently, > modules' symbols are sometimes resolved fine, sometimes they're > bogus but point to the module at least (not some other random > code), but eventually they are just nonsense addresses. > > Regarding the choice of using the MSB to store if an addr is core > kernel or module, well this was also a choice taking into account > simplicity and performance, lemme know please if it's no good and > any suggestions on how to better do it, I can easily re-implement! > Thanks again, > > Guilherme >
Hi Kees, gentle ping about this one - lemme know if you have suggestions or questions, and thanks in advance =) Guilherme
