linux-kernel - Re: [PATCH 2/3] perf: collect BPF metadata from existing BPF programs

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] [day] [month] [year] [list]

Message-ID: <CAP_z_CjQktMSMVhgX1gBkBh+0sAnWwAjUfBgJ1he1oaR7ULeRg@mail.gmail.com>
Date: Wed, 4 Jun 2025 16:04:09 -0700
From: Blake Jones <blakejones@...gle.com>
To: Arnaldo Carvalho de Melo <acme@...nel.org>
Cc: Namhyung Kim <namhyung@...nel.org>, Song Liu <song@...nel.org>, Jiri Olsa <jolsa@...nel.org>, 
	Alexei Starovoitov <ast@...nel.org>, Daniel Borkmann <daniel@...earbox.net>, 
	Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau <martin.lau@...ux.dev>, 
	Eduard Zingerman <eddyz87@...il.com>, Yonghong Song <yonghong.song@...ux.dev>, 
	John Fastabend <john.fastabend@...il.com>, KP Singh <kpsingh@...nel.org>, 
	Stanislav Fomichev <sdf@...ichev.me>, Hao Luo <haoluo@...gle.com>, 
	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...hat.com>, 
	Mark Rutland <mark.rutland@....com>, 
	Alexander Shishkin <alexander.shishkin@...ux.intel.com>, Ian Rogers <irogers@...gle.com>, 
	Adrian Hunter <adrian.hunter@...el.com>, Kan Liang <kan.liang@...ux.intel.com>, 
	Chun-Tse Shao <ctshao@...gle.com>, Zhongqiu Han <quic_zhonhan@...cinc.com>, 
	James Clark <james.clark@...aro.org>, Charlie Jenkins <charlie@...osinc.com>, 
	Andi Kleen <ak@...ux.intel.com>, Dmitry Vyukov <dvyukov@...gle.com>, Leo Yan <leo.yan@....com>, 
	Yujie Liu <yujie.liu@...el.com>, Graham Woodward <graham.woodward@....com>, 
	Yicong Yang <yangyicong@...ilicon.com>, Ben Gainey <ben.gainey@....com>, 
	linux-kernel@...r.kernel.org, bpf@...r.kernel.org, 
	linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 2/3] perf: collect BPF metadata from existing BPF programs

On Wed, Jun 4, 2025 at 3:12 PM Arnaldo Carvalho de Melo <acme@...nel.org> wrote:
> So, the comment in:
>
> tools/perf/util/bpf-event.c
>
> Is:
>
>  * Synthesize PERF_RECORD_KSYMBOL and PERF_RECORD_BPF_EVENT for one bpf
>  * program. One PERF_RECORD_BPF_EVENT is generated for the program. And
>  * one PERF_RECORD_KSYMBOL is generated for each sub program.
>
> which is not so nicely worded tho :-\
>
> "One KSYMBOL per program", followed by "one KSYMBOL per sub program".
>
> But that matches the referenced:
>
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/kernel/events/core.c?h=v6.15#n9825

Indeed, we get one KSYMBOL per subprogram, but one BPF_EVENT per program.
(I found that the term "subprogram" is used inconsistently; sometimes it
includes the main program, while other times it doesn't. In the case of
that comment, and the function perf_event__synthesize_one_bpf_prog, it does
include the main program, which has sub_id = 0.)

> So, for these bpf_metadata_ variables, would that be strictly per
> program or would it be perf 'sub program'?

These BPF metadata records would be generated for each subprogram.

My goal here is to allow PERF_RECORD_SAMPLE events with IPs in BPF code
to be associated with any metadata that describes that code. As the
comment points out, each subprogram gets its own PERF_RECORD_KSYMBOL event,
and that event indicates where the subprogram's starting and ending
addresses are. With one PERF_RECORD_BPF_METADATA event per subprogram, it's
then straightforward to associate the metadata with a range of IPs.

If I only generated the metadata records per program rather than per
subprogram, I could only associate them with a PERF_RECORD_BPF_EVENT event.
That event has the full program's tag, but it doesn't have a list of the
subprogram tags for that program. So it doesn't have enough information on
its own to construct the relevant list of virtual address ranges. And I'd
be quite concerned about assuming that the BPF_EVENT events immediately
follow their related KSYMBOL events, especially for events generated while
the system was generating SAMPLE events.

Blake

> Couldn't get an answer from looking at tools/bpf/bpftool/prog.c, but
> seems to be with progs, not subprogs, i.e. just the PERF_RECORD_KSYMBOL
> associated with progs (not subprogs) will have those variables.
>
> But then it seems those variables _are_ associated with at least one
> PERF_RECORD_KSYMBOL, right?