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

From: Eric Leblond <[email-masked]>
Date: Sun, 28 Jan 2018 10:38:23 +0100

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 <[email-masked]>
Blog: https://home.regit.org/