linux-kernel - Re: [PATCH v2 0/2] 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: <20250205212543.42bd11a8093a074e9df27670@kernel.org>
Date: Wed, 5 Feb 2025 21:25:43 +0900
From: Masami Hiramatsu (Google) <mhiramat@...nel.org>
To: Steven Rostedt <rostedt@...dmis.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: [PATCH v2 0/2] tracing: Introduce relative stacktrace

On Mon, 3 Feb 2025 10:32:34 -0500
Steven Rostedt <rostedt@...dmis.org> wrote:

> On Sat,  1 Feb 2025 16:23:00 +0900
> "Masami Hiramatsu (Google)" <mhiramat@...nel.org> wrote:
> 
> > Hi,
> > 
> > Here is the 2nd version of adding relative stacktrace for tracing.
> > The previous version is here;
> > 
> > https://lore.kernel.org/all/173807861687.1525539.15082309716909038251.stgit@mhiramat.roam.corp.google.com/
> > 
> > In this version, I changed the idea to only use the first 32bit of
> > the build_id of the modules instead of using live hash/id to identify
> > the module. Also, save the offset from the .text section for each
> > module instead of using the offset from the _stext for the module
> > address. (For the core kernel text address, keep using the offset
> > from _stext.)
> > 
> > This brings the following benefits:
> >  - Do not need to save the live module allocation information on
> >    somewhere in the reserved memory.
> >  - Easy to find the module offline.
> >  - We can ensure there are only offsets from the base, no KASLR info.
> > 
> > Moreover, encode/decode module build_id, we can show the module name
> > with the symbols on stacktrace.
> > 
> > Thus, this relative stacktrace is a better option for the persistent
> > ring buffer with security restricted environment (e.g. no kallsyms
> > access from user.)
> > 
> >  # echo 1 > options/relative-stacktrace 
> >  # modprobe trace_events_sample
> >  # echo stacktrace > events/sample-trace/foo_bar/trigger 
> >  # cat trace 
> >     event-sample-1622    [004] ...1.   397.542659: <stack trace>
> >  => event_triggers_post_call
> >  => trace_event_raw_event_foo_bar [trace_events_sample]
> >  => do_simple_thread_func [trace_events_sample]
> >  => simple_thread [trace_events_sample]
> >  => kthread
> >  => ret_from_fork
> >  => ret_from_fork_asm  
> >
> 
> I thought we decided that we didn't need the relative stack trace? That all
> we need to do is to expose the offset from the last boot, and a list of
> modules that were loaded and their addresses, and then we can easily
> decipher the stack traces into human readable format?

Hmm, if it is for the last boot, it is OK. So when the user mmapped the
buffer before using it for trace, such base-address metadata will be
exposed, and after using the trace, it is not exposed because that will
leak the current boot base address? (Or we can expose that?)

I meant that exposing the table for previous boot is safe, but it may
not be allowed for the live tracing. That is my concern.

Anyway, let me try storing the module table.

Thank you,

> 
> -- Steve
> 


-- 
Masami Hiramatsu (Google) <mhiramat@...nel.org>