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