linux-kernel - Re: [PATCH 2/2] Revert "perf tools: Fix arm64 build by generating unistd

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

Message-ID: <CAP-5=fV-miOrYn+xNVAjZZsa3hPYncZoB6-ZtsMP2n9Zhm2sAA@mail.gmail.com>
Date: Tue, 9 Dec 2025 08:37:55 -0800
From: Ian Rogers <irogers@...gle.com>
To: Leo Yan <leo.yan@....com>
Cc: Arnaldo Carvalho de Melo <acme@...nel.org>, Namhyung Kim <namhyung@...nel.org>, Jiri Olsa <jolsa@...nel.org>, 
	Adrian Hunter <adrian.hunter@...el.com>, James Clark <james.clark@...aro.org>, 
	linux-kernel@...r.kernel.org, linux-perf-users@...r.kernel.org
Subject: Re: [PATCH 2/2] Revert "perf tools: Fix arm64 build by generating unistd_64.h"

On Tue, Dec 9, 2025 at 2:49 AM Leo Yan <leo.yan@....com> wrote:
>
> Hi Ian,
>
> On Fri, Dec 05, 2025 at 09:16:32AM -0800, Ian Rogers wrote:
>
> [...]
>
> > > For a neat fix, I think we can remove all unistd.h headers:
> > >
> > >   $ ls tools/arch/*/include/uapi/asm/unistd*
> > >   tools/arch/arc/include/uapi/asm/unistd.h
> > >   tools/arch/hexagon/include/uapi/asm/unistd.h
> > >   tools/arch/riscv/include/uapi/asm/unistd.h
> > >   tools/arch/x86/include/uapi/asm/unistd_64.h
> > >   tools/arch/arm64/include/uapi/asm/unistd.h
> > >   tools/arch/loongarch/include/uapi/asm/unistd.h
> > >   tools/arch/x86/include/uapi/asm/unistd_32.h
> > >   tools/arch/x86/include/uapi/asm/unistd.h
> > >
> > > Any concern?  I would get maintainers's confirmation before proceeding.
> >
> > Thanks Leo! The tools/include directory is a concern for me as the use
> > of it is pretty unstructured. For example, what does <linux/types.h>
> > refer to?
>
> I understand your concern.
>
> For my current work, I would like to constraint to unistd.h headers
> only, now this is breaking BPF skeleton building on Arm64.
>
> I did not observe other building failures, so we can polish other
> headers later.
>
> > Thanks for doing the build testing! Doing a simpler grep:
> > ```
> > $ grep -r "asm/unistd" tools/include tools/perf tools/lib
> > tools/perf/check-headers.sh:  "arch/x86/include/uapi/asm/unistd.h"
> > tools/perf/check-headers.sh:  "arch/arm64/include/uapi/asm/unistd.h"
> > tools/lib/bpf/bpf.c:#include <asm/unistd.h>
> > tools/lib/bpf/libbpf.c:#include <asm/unistd.h>
> > ```
> > I think unistd.h is needed to make things hermetic for libbpf :-( ...
> > Anyway, I think getting rid of unistd.h is a good
> > thing but it will probably break perf's build that invokes libbpf's
> > build because libbpf will be mixing kernel and old libc headers on one
> > of the maintainers build test platforms (likely an old one) where the
> > type collisions yield compile time errors. To avoid that I'd suggest
> > making libbpf not use asm/unistd.h as a first step. We could get lucky
> > with something non-hermetic, but it wouldn't be my preference.
>
> Based on my test, perf (including libbpf) builds successfully without
> relying on the unistd.h headers under tools/arch.
>
> To verify which "unistd.h" headers are actually included, I searched
> dependencies recorded in .cmd files:
>
>   grep -r --include="*.cmd" "unistd.h" /data_nvme1n1/niayan01/upstream/build/
>
> See the complete log: https://termbin.com/9w85
>
> The mentioned libbpf building includes "unistd.h" headers from the toolchain
> and can build successfully.  I verified with two GCC toolchains:
>
>   # aarch64-linux-gnu-gcc --version
>   aarch64-linux-gnu-gcc (Ubuntu 9.4.0-1ubuntu1~20.04.2) 9.4.0
>   Copyright (C) 2019 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>   # aarch64-linux-gnu-gcc --version
>   aarch64-linux-gnu-gcc (Ubuntu 13.3.0-6ubuntu2~24.04) 13.3.0
>   Copyright (C) 2023 Free Software Foundation, Inc.
>   This is free software; see the source for copying conditions.  There is NO
>   warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> As a side topic, given libbpf is maintained on github and can support
> standalone build [1], we should have confidence that it is not dependent on
> tools' headers.

The github project does things differently and has copied headers into
itself to make things work. It doesn't copy unistd.h:
https://github.com/libbpf/libbpf/tree/master/include/asm
but I'm not sure that means anything beyond the BPF buildbot not needing it.

> I still think removing the unistd.h headers from tools is the right thing to
> do, and based on test, it does not break perf building.

I think this is the getting lucky case I referred to :-) I can imagine
in the build environment I'm in, needing to revert the change to make
sure the headers remain hermetic. I suspect the perf on old Linux
build checks will also face a similar problem.

Thanks,
Ian

> Thanks,
> Leo
>
> [1] https://github.com/libbpf/libbpf?tab=readme-ov-file#building-libbpf