linux-kernel - Re: [RFC PATCH 0/3] tracing: Introduce relative stacktrace

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: <20250128200939.0cbce825@batman.local.home>
Date: Tue, 28 Jan 2025 20:09:38 -0500
From: Steven Rostedt <rostedt@...dmis.org>
To: "Masami Hiramatsu (Google)" <mhiramat@...nel.org>
Cc: Mathieu Desnoyers <mathieu.desnoyers@...icios.com>, Luis Chamberlain
 <mcgrof@...nel.org>, Petr Pavlu <petr.pavlu@...e.com>, Sami Tolvanen
 <samitolvanen@...gle.com>, Daniel Gomez <da.gomez@...sung.com>,
 linux-kernel@...r.kernel.org, linux-trace-kernel@...r.kernel.org,
 linux-modules@...r.kernel.org
Subject: Re: [RFC PATCH 0/3] tracing: Introduce relative stacktrace

On Wed, 29 Jan 2025 09:58:19 +0900
Masami Hiramatsu (Google) <mhiramat@...nel.org> 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