linux-kernel - Re: [PATCH] perf tools: Allow build-id with trailing zeros

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: <CAM9d7chp-B3i0KURk5ptKZsQOE-UJ=jwfAtvADEg-PObNysFAQ@mail.gmail.com>
Date:   Fri, 10 Sep 2021 15:38:29 -0700
From:   Namhyung Kim <namhyung@...nel.org>
To:     Jiri Olsa <jolsa@...hat.com>
Cc:     Arnaldo Carvalho de Melo <acme@...nel.org>,
        Ingo Molnar <mingo@...nel.org>,
        Peter Zijlstra <peterz@...radead.org>,
        LKML <linux-kernel@...r.kernel.org>,
        Andi Kleen <ak@...ux.intel.com>,
        Ian Rogers <irogers@...gle.com>
Subject: Re: [PATCH] perf tools: Allow build-id with trailing zeros

Hi Jiri,

On Fri, Sep 10, 2021 at 12:41 PM Jiri Olsa <jolsa@...hat.com> wrote:
>
> On Fri, Sep 10, 2021 at 09:41:50AM -0700, Namhyung Kim wrote:
> > Current perf saves a build-id with size but old versions assumes the
> > size of 20.  In case the build-id is less than 20 (like for MD5), it'd
> > fill the rest with 0s.
> >
> > I saw a problem when old version of perf record saved binary in the
> > build-id cache and new version of perf reads the data.  The symbols
> > should be read from the build-id cache (as the path no longer has the
> > same binary) but it failed due to mismatch in the build-id.
> >
> >   symsrc__init: build id mismatch for /home/namhyung/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf.
> >
> > The build-id event in the data has 20 byte build-ids, but it saw a
> > different size (16) when it reads the build-id of the elf file in the
> > build-id cache.
> >
> >   $ readelf -n ~/.debug/.build-id/53/e4c2f42a4c61a2d632d92a72afa08f00000000/elf
> >
> >   Displaying notes found in: .note.gnu.build-id
> >     Owner                Data size    Description
> >     GNU                  0x00000010   NT_GNU_BUILD_ID (unique build ID bitstring)
> >       Build ID: 53e4c2f42a4c61a2d632d92a72afa08f
> >
> > Let's fix this by allowing trailing zeros if the size is different.
> >
> > Fixes: 39be8d0115b3 ("perf tools: Pass build_id object to dso__build_id_equal()")
> >
> > Signed-off-by: Namhyung Kim <namhyung@...nel.org>
> > ---
> >  tools/perf/util/dso.c | 12 ++++++++++++
> >  1 file changed, 12 insertions(+)
> >
> > diff --git a/tools/perf/util/dso.c b/tools/perf/util/dso.c
> > index ee15db2be2f4..0c0dd877d4e9 100644
> > --- a/tools/perf/util/dso.c
> > +++ b/tools/perf/util/dso.c
> > @@ -1349,6 +1349,18 @@ void dso__set_build_id(struct dso *dso, struct build_id *bid)
> >
> >  bool dso__build_id_equal(const struct dso *dso, struct build_id *bid)
> >  {
> > +     static const char zeros[BUILD_ID_SIZE];
> > +
> > +     if (dso->bid.size > bid->size && dso->bid.size == BUILD_ID_SIZE) {
> > +             /*
> > +              * For the backward compatibility, it allows a build-id has
> > +              * trailing zeros.
> > +              */
> > +             return !memcmp(dso->bid.data, bid->data, bid->size) &&
> > +                     !memcmp(&dso->bid.data[bid->size], zeros,
> > +                             dso->bid.size - bid->size);
>
> we now have memchr_inv in tools, so you could use:
>   memchr_inv(&dso->bid.data[bid->size], 0, dso->bid.size - bid->size);
>
> and save 20 bytes in bss ;-) other than that, nice catch
>
> Acked-by: Jiri Olsa <jolsa@...hat.com>

right, will update!

Thanks,
Namhyung