netdev - BPF, cross-compiling, and selftests

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-next>] [day] [month] [year] [list]

Date:   Tue, 15 Nov 2022 13:36:08 +0100
From:   Björn Töpel <bjorn@...nel.org>
To:     bpf@...r.kernel.org, netdev@...r.kernel.org
Cc:     Anders Roxell <anders.roxell@...aro.org>
Subject: BPF, cross-compiling, and selftests

I ran into build issues when building selftests/net on Ubuntu/Debian,
which is related to that BPF program builds usually needs libc (and the
corresponding target host configuration/defines).

When I try to build selftests/net, on my Debian host I get:

  clang -O2 -target bpf -c bpf/nat6to4.c -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o
  In file included from bpf/nat6to4.c:27:
  In file included from /usr/include/linux/bpf.h:11:
  /usr/include/linux/types.h:5:10: fatal error: 'asm/types.h' file not found
  #include <asm/types.h>
           ^~~~~~~~~~~~~
  1 error generated.

asm/types.h lives in /usr/include/"TRIPLE" on Debian, say
/usr/include/x86_64-linux-gnu. Target BPF does not (obviously) add the
x86-64 search path. These kind of problems have been worked around in,
e.g., commit 167381f3eac0 ("selftests/bpf: Makefile fix "missing"
headers on build with -idirafter").

However, just adding the host specific path is not enough. Typically,
when you start to include libc files, like "sys/socket.h" it's
expected that host specific defines are set. On my x86-64 host:

  $ clang -dM -E - < /dev/null|grep x86_
  #define __x86_64 1
  #define __x86_64__ 1

  $ clang -target riscv64-linux-gnu -dM -E - < /dev/null|grep xlen
  #define __riscv_xlen 64

otherwise you end up with errors like the one below.

Missing __x86_64__:
  #if !defined __x86_64__
  # include <gnu/stubs-32.h>
  #endif

  clang -O2 -target bpf -c bpf/nat6to4.c -idirafter /usr/lib/llvm-16/lib/clang/16.0.0/include -idirafter /usr/local/include -idirafter /usr/include/x86_64-linux-gnu -idirafter /usr/include  -Wno-compare-distinct-pointer-types -I../../bpf -I../../../../lib -I../../../../../usr/include/ -o /home/bjorn/src/linux/linux/tools/testing/selftests/net/bpf/nat6to4.o
  In file included from bpf/nat6to4.c:28:
  In file included from /usr/include/linux/if.h:28:
  In file included from /usr/include/x86_64-linux-gnu/sys/socket.h:22:
  In file included from /usr/include/features.h:510:
  /usr/include/x86_64-linux-gnu/gnu/stubs.h:7:11: fatal error: 'gnu/stubs-32.h' file not found
  # include <gnu/stubs-32.h>
            ^~~~~~~~~~~~~~~~
  1 error generated.

Now, say that we'd like to cross-compile for a platform. Should I make
sure that all the target compiler's "default defines" are exported to
the BPF-program build step? I did a hack for RISC-V a while back in
commit 6016df8fe874 ("selftests/bpf: Fix broken riscv build"). Not
super robust, and not something I'd like to see for all supported
platforms.

Any ideas? Maybe a convenience switch to Clang/target bpf? :-)

Björn