patches and low-level development discussion
 help / color / mirror / code / Atom feed
From: Alyssa Ross <hi@alyssa.is>
To: Demi Marie Obenour <demiobenour@gmail.com>
Cc: Spectrum OS Development <devel@spectrum-os.org>
Subject: Re: [PATCH v3] tools/xdp-forwarder: Do not include libc headers in eBPF programs
Date: Sat, 18 Oct 2025 12:56:53 +0200	[thread overview]
Message-ID: <87a51ojx56.fsf@alyssa.is> (raw)
In-Reply-To: <20251008-fix-forwarder-build-v3-1-a93e5156fb6a@gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4633 bytes --]

Demi Marie Obenour <demiobenour@gmail.com> writes:

> The build happened to work on arm64 because the glibc arm64 headers
> don't support multilib.  On x86_64, glibc headers assume that BPF is a
> 32-bit platform (because __x86_64__ isn't defined) and fail to find the
> 32-bit headers.  This is not a glibc bug.  Rather, BPF programs should
> not be including glibc headers.
>
> Most Linux headers are not trivial to include in BPF programs.  The
> version of the headers meant for userspace use do include glibc headers,
> and that isn't supported in BPF.  The version meant for building
> kernel modules does not, but using it requires much more complicated
> build system.
>
> Solve this problem by only including headers intended for use in BPF
> programs.  These headers include declarations explicitly intended for
> use in BPF programs, so if they do pull in libc headers that is a bug.
> This also allows using an unwrapped clang.  Nix's wrapped clang is not
> suitable when a target is explicitly specified, so this is another a
> bug fix.
>
> This prevents vendoring the example headers, so replace them with a
> header that only includes common functionality common to both eBPF
> programs.  A single struct including both Ethernet II and 802.1Q headers
> is used, massively simplifying the code.

Could we put that cleanup into a separate patch, and keep this patch as
the smallest change possible necessary to fix the build?

> diff --git a/tools/default.nix b/tools/default.nix
> index 2c6846c80073e7b64fb7a19488103f6cf97a4420..8fd3491010303f981dac80cd6581614d594f993c 100644
> --- a/tools/default.nix
> +++ b/tools/default.nix
> @@ -6,7 +6,7 @@ import ../lib/call-package.nix (
>  { src, lib, stdenv, fetchCrate, fetchurl, runCommand, buildPackages
>  , meson, ninja, pkg-config, rustc
>  , clang-tools, clippy, jq
> -, dbus
> +, dbus, linuxHeaders
>  # clang 19 (current nixpkgs default) is too old to support -fwrapv-pointer
>  , clang_21, libbpf
>  , buildSupport ? false
> @@ -88,7 +88,7 @@ stdenv.mkDerivation (finalAttrs: {
>      ++ lib.optionals (appSupport || driverSupport) [ pkg-config ]
>      ++ lib.optionals hostSupport [ rustc ]
>      ++ lib.optionals driverSupport [ clang_21 ];
> -  buildInputs = lib.optionals appSupport [ dbus ] ++ lib.optionals driverSupport [ libbpf ];
> +  buildInputs = lib.optionals appSupport [ dbus ] ++ lib.optionals driverSupport [ libbpf linuxHeaders ];
>  
>    postPatch = lib.optionals hostSupport (lib.concatMapStringsSep "\n" (crate: ''
>      mkdir -p subprojects/packagecache
> @@ -104,11 +104,11 @@ stdenv.mkDerivation (finalAttrs: {
>      "-Dtests=false"
>      "-Dunwind=false"
>      "-Dwerror=true"
> +  ] ++ lib.optionals driverSupport [
> +    "-Dclang=${clang_21.cc}/bin/clang"

llvmPackages_21.clang-unwrapped would prevent having to go through the
unwrapped compiler.

> +    "-Dlinux-headers=${linuxHeaders}/include"
>    ];
>  
> -  # Not supported for target bpf
> -  hardeningDisable = lib.optionals driverSupport [ "zerocallusedregs" ];
> -
>    passthru.tests = {
>      clang-tidy = finalAttrs.finalPackage.overrideAttrs (
>        { name, src, nativeBuildInputs ? [], ... }:
> diff --git a/tools/meson.options b/tools/meson.options
> index 301efb9f677fdec57c8491fd6a6868f2d35cb076..2aa82a3188f2912487d075c8f320a63c14878f91 100644
> --- a/tools/meson.options
> +++ b/tools/meson.options
> @@ -13,6 +13,13 @@ option('driver', type : 'boolean', value : false,
>  option('hostfsrootdir', type : 'string', value : '/run/host',
>    description : 'Path where the virtio-fs provided by the host will be mounted')
>  
> +option('clang', type : 'string',
> +  description : 'Path to clang')
> +
> +option('linux-headers',
> +  type : 'string',
> +  description : 'Path to Linux kernel headers')

Let's make this the package prefix, rather than the include directory.

> +
>  option('tests',
>    type : 'boolean',
>    description : 'Build tests')
> diff --git a/tools/xdp-forwarder/meson.build b/tools/xdp-forwarder/meson.build
> index b73130eb27b8000a102b0a8847ecb06b93a955d2..dec75c55884c4317af747b9a12e8f791d09d0a19 100644
> --- a/tools/xdp-forwarder/meson.build
> +++ b/tools/xdp-forwarder/meson.build
> @@ -9,10 +9,18 @@ executable('set-router-iface', 'set_router_iface.c',
>    dependencies : libbpf,
>    install : true)
>  
> -clang = find_program('clang', native : true)
> +clang_path = get_option('clang')
> +if clang_path == ''
> +  error('clang must be provided to build XDP forwarder')
> +endif

What was wrong with find_program()?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

      reply	other threads:[~2025-10-18 10:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-10-03 17:14 [PATCH] tools/xdp-forwarder: Fix build Demi Marie Obenour
2025-10-04 15:47 ` Alyssa Ross
2025-10-05  3:36   ` Demi Marie Obenour
2025-10-06  7:30 ` [PATCH RFC DOESNOTBUILD v2] tools/xdp-forwarder: Do not include libc headers in eBPF programs Demi Marie Obenour
2025-10-06  7:45   ` Demi Marie Obenour
2025-10-08 17:22   ` [PATCH v3] " Demi Marie Obenour
2025-10-18 10:56     ` Alyssa Ross [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87a51ojx56.fsf@alyssa.is \
    --to=hi@alyssa.is \
    --cc=demiobenour@gmail.com \
    --cc=devel@spectrum-os.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://spectrum-os.org/git/crosvm
	https://spectrum-os.org/git/doc
	https://spectrum-os.org/git/mktuntap
	https://spectrum-os.org/git/nixpkgs
	https://spectrum-os.org/git/spectrum
	https://spectrum-os.org/git/ucspi-vsock
	https://spectrum-os.org/git/www

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).