netdev - Re: [bpf-next PATCH 5/5] tools/libbpf: handle issues with bpf ELF objects containing .eh

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]

Message-ID: <1517132303.29685.1.camel@regit.org>
Date:   Sun, 28 Jan 2018 10:38:23 +0100
From:   Eric Leblond <eric@...it.org>
To:     Jesper Dangaard Brouer <brouer@...hat.com>, netdev@...r.kernel.org,
        Daniel Borkmann <borkmann@...earbox.net>,
        Alexei Starovoitov <alexei.starovoitov@...il.com>,
        wangnan0@...wei.com
Cc:     acme@...hat.com, joe@....org, jakub.kicinski@...ronome.com
Subject: Re: [bpf-next PATCH 5/5] tools/libbpf: handle issues with bpf ELF
 objects containing .eh_frames

Hi,

On Sat, 2018-01-27 at 18:27 +0100, Jesper Dangaard Brouer wrote:
> If clang >= 4.0.1 is missing the option '-target bpf', it will cause
> llc/llvm to create two ELF sections for "Exception Frames", with
> section names '.eh_frame' and '.rel.eh_frame'.
> 
> The BPF ELF loader library libbpf fails when loading files with these
> sections.  The other in-kernel BPF ELF loader in
> samples/bpf/bpf_load.c,
> handle this gracefully. And iproute2 loader also seems to work with
> these
> "eh" sections.
> 
> The issue in libbpf is caused by bpf_object__elf_collect() skip the
> '.eh_frame' and thus doesn't create an internal data structure
> pointing to this ELF section index.  Later when the relocation
> section
> '.rel.eh_frame' is processed, it tries to find the '.eh_frame' via
> the
> ELF section idx, which is that fails (in bpf_object__collect_reloc).
> 
> I couldn't find a way to see that the '.rel.eh_frame' was irrelevant
> (that is only determined by looking at the section it reference,
> which
> we no longer have info available on).
> 
> Thus, my solution is simply to match on the name of the relocation
> section, to skip that too.

I confirm this fixes the issue I have seen when loading XDP filter with
libbpf in Suricata.

BR,
-- 
Eric Leblond <eric@...it.org>
Blog: https://home.regit.org/