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]

Date:   Wed, 7 Feb 2018 17:18:38 +0100
From:   Daniel Borkmann <daniel@...earbox.net>
To:     Jesper Dangaard Brouer <brouer@...hat.com>
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>
Subject: Re: [bpf-next V2 PATCH 5/5] tools/libbpf: handle issues with bpf ELF
 objects containing .eh_frames

On 02/07/2018 03:58 PM, Jesper Dangaard Brouer wrote:
> 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 ?

Well, see what /usr/include/gnu/stubs.h is doing, on x86_64 it's:

  #if !defined __x86_64__
  # include <gnu/stubs-32.h>
  #endif
  #if defined __x86_64__ && defined __LP64__
  # include <gnu/stubs-64.h>
  #endif
  #if defined __x86_64__ && defined __ILP32__
  # include <gnu/stubs-x32.h>
  #endif

If you do clang -target bpf, then clang will have '__bpf__' defined instead
of '__x86_64__' hence the gnu/stubs-32.h include attempt, and the workaround
used in selftests with -D__x86_64__. But the -D__x86_64__ is not portable, so
yeah, either dummy stubs if you need to include the headers or also other the
workaround you mention below.

[...]
>> 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