linux-kernel - Re: [PATCH 1/2] perf tools: Add more weak libbpf functions

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, 10 Nov 2021 09:39:20 +0100
From:   Jiri Olsa <jolsa@...hat.com>
To:     Ian Rogers <irogers@...gle.com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        lkml <linux-kernel@...r.kernel.org>,
        Peter Zijlstra <a.p.zijlstra@...llo.nl>,
        Ingo Molnar <mingo@...nel.org>,
        Mark Rutland <mark.rutland@....com>,
        Namhyung Kim <namhyung@...nel.org>,
        Alexander Shishkin <alexander.shishkin@...ux.intel.com>,
        Michael Petlan <mpetlan@...hat.com>,
        linux-perf-users@...r.kernel.org,
        Andrii Nakryiko <andrii@...nel.org>
Subject: Re: [PATCH 1/2] perf tools: Add more weak libbpf functions

On Tue, Nov 09, 2021 at 10:49:53AM -0800, Ian Rogers wrote:
> On Tue, Nov 9, 2021 at 6:07 AM Jiri Olsa <jolsa@...hat.com> wrote:
> >
> > We hit the window where perf uses libbpf functions, that did not
> > make it to the official libbpf release yet and it's breaking perf
> > build with dynamicly linked libbpf.
> >
> > Fixing this by providing the new interface as weak functions which
> > calls the original libbpf functions. Fortunatelly the changes were
> > just renames.
> 
> Could we just provide these functions behind a libbpf version #if ?
> Weak symbols break things in subtle ways, under certain circumstances
> the weak symbol is preferred over the strong due to lazy object file
> resolution:
> https://maskray.me/blog/2021-06-20-symbol-processing#archive-processing
> This bit me last week, but in general you get away with it as the lazy
> object file will get processed in an archive exposing the strong
> symbol. With an #if you either get a linker error for 2 definitions or
> 0 definitions, and it's clear what is broken.

hum, I see 2 problems..

usinf #if works nicely for btf__raw_data because it's used directly,
but bpf_object__next_program and bpf_object__next_map are used
through macros:

   #define bpf_object__for_each_map(pos, obj)              \
        for ((pos) = bpf_object__next_map((obj), NULL); \
             (pos) != NULL;                             \
             (pos) = bpf_object__next_map((obj), (pos)))

   #define bpf_object__for_each_program(pos, obj)                  \
        for ((pos) = bpf_object__next_program((obj), NULL);     \
             (pos) != NULL;                                     \
             (pos) = bpf_object__next_program((obj), (pos)))

we would need to provide 'old version' macro as well


another issue is more disturbing.. compiling with LIBBPF_DYNAMIC=1
still seems to take the in-kernel bpf headers, because we use 

  -I$(KTREE)/tools/lib

so any include with '<bpf/...> will pick up the kernel version
and not the one in /usr/include, perhaps the order of '-I...'
could help, I need to check

jirka

> 
> In the past we had problems due to constant propagation from weak
> const variables, where #if was the solution:
> https://lore.kernel.org/lkml/20191001003623.255186-1-irogers@google.com/
> 
> There was some recent conversation on libbpf version for pahole here:
> https://lore.kernel.org/bpf/CAP-5=fUc3LtU0WYg-Py9Jf+9picaWHJdSw=sdOMA54uY3p1pdw@mail.gmail.com/T/
> https://lore.kernel.org/bpf/20211021183330.460681-1-irogers@google.com/
> 
> Thanks,
> Ian
> 
> > Signed-off-by: Jiri Olsa <jolsa@...nel.org>
> > ---
> >  tools/perf/util/bpf-event.c | 27 +++++++++++++++++++++++++++
> >  1 file changed, 27 insertions(+)
> >
> > diff --git a/tools/perf/util/bpf-event.c b/tools/perf/util/bpf-event.c
> > index 4d3b4cdce176..ceb96360fd12 100644
> > --- a/tools/perf/util/bpf-event.c
> > +++ b/tools/perf/util/bpf-event.c
> > @@ -33,6 +33,33 @@ struct btf * __weak btf__load_from_kernel_by_id(__u32 id)
> >         return err ? ERR_PTR(err) : btf;
> >  }
> >
> > +struct bpf_program * __weak
> > +bpf_object__next_program(const struct bpf_object *obj, struct bpf_program *prev)
> > +{
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > +       return bpf_program__next(prev, obj);
> > +#pragma GCC diagnostic pop
> > +}
> > +
> > +struct bpf_map * __weak
> > +bpf_object__next_map(const struct bpf_object *obj, const struct bpf_map *prev)
> > +{
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > +       return bpf_map__next(prev, obj);
> > +#pragma GCC diagnostic pop
> > +}
> > +
> > +const void * __weak
> > +btf__raw_data(const struct btf *btf_ro, __u32 *size)
> > +{
> > +#pragma GCC diagnostic push
> > +#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
> > +       return btf__get_raw_data(btf_ro, size);
> > +#pragma GCC diagnostic pop
> > +}
> > +
> >  static int snprintf_hex(char *buf, size_t size, unsigned char *data, size_t len)
> >  {
> >         int ret = 0;
> > --
> > 2.31.1
> >
>