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]
Date:   Wed, 12 Aug 2020 18:20:22 -0700
From:   Alexei Starovoitov <alexei.starovoitov@...il.com>
To:     Song Liu <songliubraving@...com>
Cc:     Jiri Olsa <jolsa@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
        Daniel Borkmann <daniel@...earbox.net>,
        "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
        "bpf@...r.kernel.org" <bpf@...r.kernel.org>,
        Martin Lau <kafai@...com>, Yonghong Song <yhs@...com>,
        Andrii Nakryiko <andriin@...com>,
        John Fastabend <john.fastabend@...il.com>,
        KP Singh <kpsingh@...omium.org>
Subject: Re: [RFC PATCH bpf-next] bpf: Iterate through all PT_NOTE sections
 when looking for build id

On Wed, Aug 12, 2020 at 8:27 AM Song Liu <songliubraving@...com> wrote:
>
>
>
> > On Aug 12, 2020, at 5:31 AM, Jiri Olsa <jolsa@...nel.org> wrote:
> >
> > Currently when we look for build id within bpf_get_stackid helper
> > call, we check the first NOTE section and we fail if build id is
> > not there.
> >
> > However on some system (Fedora) there can be multiple NOTE sections
> > in binaries and build id data is not always the first one, like:
> >
> >  $ readelf -a /usr/bin/ls
> >  ...
> >  [ 2] .note.gnu.propert NOTE             0000000000000338  00000338
> >       0000000000000020  0000000000000000   A       0     0     8358
> >  [ 3] .note.gnu.build-i NOTE             0000000000000358  00000358
> >       0000000000000024  0000000000000000   A       0     0     437c
> >  [ 4] .note.ABI-tag     NOTE             000000000000037c  0000037c
> >  ...
> >
> > So the stack_map_get_build_id function will fail on build id retrieval
> > and fallback to BPF_STACK_BUILD_ID_IP.
> >
> > This patch is changing the stack_map_get_build_id code to iterate
> > through all the NOTE sections and try to get build id data from
> > each of them.
> >
> > When tracing on sched_switch tracepoint that does bpf_get_stackid
> > helper call kernel build, I can see about 60% increase of successful
> > build id retrieval. The rest seems fails on -EFAULT.
> >
> > Signed-off-by: Jiri Olsa <jolsa@...nel.org>
>
> LGTM. Thanks for the fix!
>
> Acked-by: Song Liu <songliubraving@...com>

It's a good fix.
Applied to bpf tree. Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ