linux-kernel - Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free ftrace_mod

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]

Date:   Sat, 7 Oct 2017 09:32:21 -0400
From:   Steven Rostedt <rostedt@...dmis.org>
To:     "Joel Fernandes (Google)" <joel.opensrc@...il.com>
Cc:     Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        Jessica Yu <jeyu@...nel.org>
Subject: Re: [for-next][PATCH 15/16] ftrace: Add freeing algorithm to free
 ftrace_mod_maps

On Fri, 6 Oct 2017 23:41:25 -0700
"Joel Fernandes (Google)" <joel.opensrc@...il.com> wrote:

> Hi Steve,
> 
> On Fri, Oct 6, 2017 at 11:07 AM, Steven Rostedt <rostedt@...dmis.org> wrote:
> > From: "Steven Rostedt (VMware)" <rostedt@...dmis.org>
> >
> > The ftrace_mod_map is a descriptor to save module init function names in
> > case they were traced, and the trace output needs to reference the function
> > name from the function address. But after the function is unloaded, it
> > the maps should be freed, as the rest of the function names are as well.  
> 
> Just checking for my understanding of this patch - wouldn't this also
> mean that if there were any look ups of the init functions that may be
> needed at trace output time, then those look ups wont be possible any
> more after module is unloaded?

Yes. That's true for all functions in the module. When a module is
unloaded, all references to it in kallsyms is also freed. Try it on a
current kernel. Trace a function in a module, then unload that module.
The trace data will just show the ip hex address of the module function
after that.

> 
> I guess having a reference somehow on the ftrace_mod_map descriptor if
> there are any entries in the trace buffer that need it can help
> prevent that but it could be too expensive for not much return since
> most likely the user wouldn't unload modules before trace collection
> in normal usage.

Right, I have thought about this, and I haven't come up with an
inexpensive way to do this. As this has been the default operation of
all module functions, and I haven't heard much complaining about it (I
think I may have had a single complaint), I didn't put too much effort
into it.

I need to look at the approach that Jessica sent me. Perhaps there's
ways to have all module function names be saved by a trace. But mapping
which trace buffer has these names may be difficult.

-- Steve