linux-kernel - Re: [PATCH v3 perf, bpf-next 1/4] perf, bpf: Introduce PERF_RECORD_BPF

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:   Wed, 12 Dec 2018 13:33:20 -0500
From:   Steven Rostedt <rostedt@...dmis.org>
To:     Peter Zijlstra <peterz@...radead.org>
Cc:     Song Liu <songliubraving@...com>,
        lkml <linux-kernel@...r.kernel.org>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "ast@...nel.org" <ast@...nel.org>,
        "daniel@...earbox.net" <daniel@...earbox.net>,
        Kernel Team <Kernel-team@...com>,
        "acme@...nel.org" <acme@...nel.org>
Subject: Re: [PATCH v3 perf, bpf-next 1/4] perf, bpf: Introduce
 PERF_RECORD_BPF_EVENT

On Wed, 12 Dec 2018 19:05:53 +0100
Peter Zijlstra <peterz@...radead.org> wrote:

> On Wed, Dec 12, 2018 at 05:09:17PM +0000, Song Liu wrote:
> > > And while this tracks the bpf kallsyms, it does not do all kallsyms.
> > > 
> > > .... Oooh, I see the problem, everybody is doing their own custom
> > > kallsym_{add,del}() thing, instead of having that in generic code :-(
> > > 
> > > This, for example, doesn't track module load/unload nor ftrace
> > > trampolines, even though both affect kallsyms.  
> > 
> > I think we can use PERF_RECORD_MMAP(or MMAP2) for module load/unload. 
> > That could be separate sets of patches.   
> 
> So I would actually like to move bpf_lock/bpf_kallsyms/bpf_tree +
> bpf_prog_kallsyms_*() + __bpf_address_lookup() into kernel/kallsyms.c
> and also have ftrace use that.
> 
> Because currently the ftrace stuff is otherwise invisible.
> 
> A generic kallsym register/unregister for any JIT.

That's if it needs to look up the symbols that were recorded when init
was unloaded.

The ftrace kallsyms is used to save the function names of init code
that was freed, but may have been recorded. With out the ftrace
kallsyms the functions traced at init time would just show up as hex
addresses (not very useful).

I'm not sure how BPF would need those symbols unless they were executed
during init (module or core) and needed to see what the symbols use to
be).

-- Steve