linux-kernel - Re: [PATCH 1/1] perf bpf: Move BPF disassembly routines to separate file to avoid clash with capstone bpf headers

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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <ZqqHnlgG0YS4DRAt@x1>
Date: Wed, 31 Jul 2024 15:51:10 -0300
From: Arnaldo Carvalho de Melo <acme@...nel.org>
To: Namhyung Kim <namhyung@...nel.org>
Cc: Song Liu <song@...nel.org>, Adrian Hunter <adrian.hunter@...el.com>,
	Ian Rogers <irogers@...gle.com>, Jiri Olsa <jolsa@...nel.org>,
	Kan Liang <kan.liang@...ux.intel.com>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH 1/1] perf bpf: Move BPF disassembly routines to separate
 file to avoid clash with capstone bpf headers

On Wed, Jul 31, 2024 at 10:07:50AM -0700, Namhyung Kim wrote:
> On Wed, Jul 31, 2024 at 8:12 AM Arnaldo Carvalho de Melo
> <acme@...nel.org> wrote:
> >
> > There is a clash of the libbpf and capstone libraries, that ends up
> > with:
> >
> >   In file included from /usr/include/capstone/capstone.h:325,
> >                    from util/disasm.c:1513:
> >   /usr/include/capstone/bpf.h:94:14: error: ‘bpf_insn’ defined as wrong kind of tag
> >      94 | typedef enum bpf_insn {
> >
> > So far we're just trying to avoid this by not having both headers
> > included in the same .c or .h file, do it one more time by moving the
> > BPF diassembly routines from util/disasm.c to util/disasm_bpf.c.
> >
> > This is only being hit when building with BUILD_NONDISTRO=1, i.e.
> > building with binutils-devel, that isn't the in the default build due to
> > a licencing clash. We need to reimplement what is now isolated in
> > util/disasm_bpf.c using some other library to have BPF annotation
> > feature that now only is available with BUILD_NONDISTRO=1.
> >
> > Cc: Adrian Hunter <adrian.hunter@...el.com>
> > Cc: Ian Rogers <irogers@...gle.com>
> > Cc: Jiri Olsa <jolsa@...nel.org>
> > Cc: Kan Liang <kan.liang@...ux.intel.com>
> > Cc: Namhyung Kim <namhyung@...nel.org>
> > Cc: Song Liu <song@...nel.org>
> > Signed-off-by: Arnaldo Carvalho de Melo <acme@...hat.com>
> > ---
> >  tools/perf/util/Build        |   1 +
> >  tools/perf/util/disasm.c     | 187 +--------------------------------
> >  tools/perf/util/disasm_bpf.c | 193 +++++++++++++++++++++++++++++++++++
> >  tools/perf/util/disasm_bpf.h |  12 +++
> >  4 files changed, 207 insertions(+), 186 deletions(-)
> >  create mode 100644 tools/perf/util/disasm_bpf.c
> >  create mode 100644 tools/perf/util/disasm_bpf.h
> >
> > +++ b/tools/perf/util/Build
> > @@ -13,6 +13,7 @@ perf-util-y += copyfile.o
> >  perf-util-y += ctype.o
> >  perf-util-y += db-export.o
> >  perf-util-y += disasm.o
> > +perf-util-y += disasm_bpf.o
> 
> I think this can be gated by LIBBFD and LIBBPF config, but not sure
> it can express the both requirements easily.

It is possible, but as discussed with Ian in another message, the
cheapest way to do it was, I think, like I did, in the end it is just a
stub returning an error when those libraries are not linked with perf.

When we manage to implement the disassembly of BPF using something other
than libbfd we can spend more time in this area, I think.

- Arnaldo