netdev - Re: [bpf-next V2 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: <20180207155811.4e0e18e3@redhat.com>
Date:   Wed, 7 Feb 2018 15:58:11 +0100
From:   Jesper Dangaard Brouer <brouer@...hat.com>
To:     Daniel Borkmann <daniel@...earbox.net>
Cc:     Alexei Starovoitov <alexei.starovoitov@...il.com>,
        netdev@...r.kernel.org, Daniel Borkmann <borkmann@...earbox.net>,
        wangnan0@...wei.com, jakub.kicinski@...ronome.com, joe@....org,
        acme@...hat.com, eric@...it.org, yhs@...com,
        Victor Julien <victor@...iniac.net>, brouer@...hat.com
Subject: Re: [bpf-next V2 PATCH 5/5] tools/libbpf: handle issues with bpf
 ELF objects containing .eh_frames

On Wed, 7 Feb 2018 14:19:00 +0100
Daniel Borkmann <daniel@...earbox.net> wrote:

> On 02/07/2018 01:40 PM, Jesper Dangaard Brouer wrote:
> > On Tue, 6 Feb 2018 20:05:43 +0100 Daniel Borkmann <daniel@...earbox.net> wrote:  
> >> On 02/06/2018 06:03 PM, Jesper Dangaard Brouer wrote:  
> > [...]  
> >>> [...] I plan to follow up and do a more complete solution later. This
> >>> is a workaround to get the Suricata use-case working and also that
> >>> samples/bpf/ can be loaded.    
> >>
> >> Aside from a needed fix in any case, is there a specifc reason why Suricata
> >> cannot rely on 'clang -target bpf'? Is it asm inline headers in your case?  
> > 
> > Below is the error I get when using 'clang' with '-target bpf'
> > 
> > $ dirs
> > ~/git/suricata/src/ebpf
> > 
> > $ clang -Wall -Iinclude -O2 -D__KERNEL__  -target bpf -emit-llvm -c xdp_filter.c -o - | llc -march=bpf -filetype=obj -o xdp_filter.bpf
> > In file included from xdp_filter.c:19:
> > In file included from /usr/bin/../lib64/clang/4.0.1/include/stdint.h:63:
> > In file included from /usr/include/stdint.h:26:
> > In file included from /usr/include/bits/libc-header-start.h:33:
> > In file included from /usr/include/features.h:434:
> > /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
> > # include <gnu/stubs-32.h>
> >           ^~~~~~~~~~~~~~~~
> > 
> > I'll leave it up to Eric Leblond to figure out that he need to change
> > in the eBPF programs to make it compile with '-target bpf'.  Maybe you
> > can offer him some guidance here?
> > 
> > Direct link to code:
> >  https://github.com/OISF/suricata/blob/master/ebpf/xdp_filter.c  
> 
> Sure, you just need glibc-devel.i686, see:
> 
> $ clang -Wall -Iinclude -O2 -D__KERNEL__ -target bpf -emit-llvm -c xdp_filter.c -o - | llc -march=bpf -filetype=obj -o xdp_filter.bpf
>   In file included from xdp_filter.c:19:
>   In file included from /home/darkstar/llvm/build/lib/clang/7.0.0/include/stdint.h:63:
>   In file included from /usr/include/stdint.h:25:
>   In file included from /usr/include/features.h:392:
>   /usr/include/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
>   # include <gnu/stubs-32.h>
>             ^~~~~~~~~~~~~~~~
>   1 error generated.
> # yum install glibc-devel.i686
>   [...]
> $ clang -Wall -Iinclude -O2 -D__KERNEL__ -target bpf -emit-llvm -c xdp_filter.c -o - | llc -march=bpf -filetype=obj -o xdp_filter.bpf

> $

Could you please explain why if makes a difference to install glibc-devel.i686 ?


How will people compiling suricata figure out the new dependency, that
on their 64-bit (x86_64) distro's they also need to install the 32-bit
(i686) variant of glibc-devel ?

> Alternatively, you could do something like done in selftests to provide a
> dummy, see commit 1c2dd16add7e ("selftests/bpf: get rid of -D__x86_64__").

That is a funny way to workaround the problem (having an empty
<gnu/stubs.h> file in include path), but it might be a better solution
to avoid frustrations for people compiling suricata.


An alternative solution is to NOT:
 #include <stdint.h>
 #include <string.h>

And then change:
 uint64_t -> __u64
 uint32_t -> __u32
 uint16_t -> __u16
 uint8_t  -> __u8

-- 
Best regards,
  Jesper Dangaard Brouer
  MSc.CS, Principal Kernel Engineer at Red Hat
  LinkedIn: http://www.linkedin.com/in/brouer