linux-kernel - Re: [PATCH v10 perf, bpf-next 1/9] perf, bpf: Introduce PERF_RECORD

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: <20190117125653.GF10486@hirez.programming.kicks-ass.net>
Date:   Thu, 17 Jan 2019 13:56:53 +0100
From:   Peter Zijlstra <peterz@...radead.org>
To:     Song Liu <songliubraving@...com>
Cc:     linux-kernel@...r.kernel.org, netdev@...r.kernel.org,
        acme@...nel.org, ast@...nel.org, daniel@...earbox.net,
        kernel-team@...com, dsahern@...il.com,
        Steven Rostedt <rostedt@...dmis.org>
Subject: Re: [PATCH v10 perf, bpf-next 1/9] perf, bpf: Introduce
 PERF_RECORD_KSYMBOL

On Wed, Jan 16, 2019 at 08:29:23AM -0800, Song Liu wrote:
> For better performance analysis of dynamically JITed and loaded kernel
> functions, such as BPF programs, this patch introduces
> PERF_RECORD_KSYMBOL, a new perf_event_type that exposes kernel symbol
> register/unregister information to user space.
> 
> The following data structure is used for PERF_RECORD_KSYMBOL.
> 
>     /*
>      * struct {
>      *      struct perf_event_header        header;
>      *      u64                             addr;
>      *      u32                             len;
>      *      u16                             ksym_type;
>      *      u16                             flags;
>      *      char                            name[];
>      *      struct sample_id                sample_id;
>      * };
>      */

So I've cobbled together the attached patches to see how it would work
out..

I didn't convert ftrace trampolines; because ftrace code has this
uncanny ability to make my head hurt. But I don't think it should be
hard, once one figures out the right structure to stick that
kallsym_node thing in (ftrace_ops ?!).

It is compiled only, so no testing what so ever (also, no changelogs).

I didn't wire up the KSYM_TYPE thing; I'm wondering if we really need
that, OTOH it really doesn't hurt having it either.

One weird thing I noticed, wth does bpf_prog_kallsyms_add() check
CAP_ADMIN ?! Surely even a non-priv JIT'ed program generates symbols,
why hide those?

Anyway; with the one nit about the get_names() thing sorted:

Acked-by: Peter Zijlstra (Intel) <peterz@...radead.org>

(thanks for sticking with this)

View attachment "peterz-latch-next.patch" of type "text/x-diff" (1812 bytes)

View attachment "peterz-kallsym.patch" of type "text/x-diff" (7531 bytes)

View attachment "peterz-kallsym-bpf.patch" of type "text/x-diff" (9921 bytes)