On Tue, 28 Jan 2025 20:09:38 -0500 Steven Rostedt <rostedt@xxxxxxxxxxx> wrote: > On Wed, 29 Jan 2025 09:58:19 +0900 > Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx> wrote: > > > Hmm, that also works if we only consider the kallsyms access. But that > > means to export KASLR information in the trace buffer. We need to check > > it is OK. > > If they say we can't have KASLR information in the ring buffer then > that is pretty much a brick wall, and we are done with this. The best > we can do is to prevent reading the current trace buffer. But honestly, > we want that too. Heck, already get kernel stack traces from perfetto > right? That has KASLR information doesn't it? I read the perfetto callstack feature, but it seems to support user space callstack. https://perfetto.dev/docs/quickstart/callstack-sampling > > > > > My another concern is how to handle this stacktrace on live system. The > > stacktrace has to be handled in both crash and live trace, but in both case > > we need to consider not leaking KASLR offset. > > I don't think we do. I meant that my [PATCH 3/3] can do it intermediately (not directly). So I think your idea (storing relative offset from module) is better. > > > > > Hmm, for avoiding the security concern, as Steve said, we may need to save > > the module relative address, which may introduce a bit more overhead, but > > it should be safer. > > Actually, if we save the addresses of where the modules are in the > persistent ring buffer, and expose the addresses only if they are from > the previous boot (if it's the current boot, it just says "current"), > then we can decipher the modules from the previous boot. OK, but when would we save it? it is OK to do it in panic()? > > > > > Anyway, this v1 may be able to leak the KASLR offset (or estimate it easier). > > I think we have 2 options; (A) as Mathieu pointed, expose the offset > > information via trace buffer. (B) as Steve pointed, fully relative offset > > in stacktrace. > > It should be fine to read the full offsets. Again, perf already does this. Indeed. Hmm, I need to know how perf solve this limitation. Thank you, > > -- Steve -- Masami Hiramatsu (Google) <mhiramat@xxxxxxxxxx>
