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

Message-ID: <20251209104926.GS724103@e132581.arm.com>
Date: Tue, 9 Dec 2025 10:49:26 +0000
From: Leo Yan <leo.yan@....com>
To: Ian Rogers <irogers@...gle.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"

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.

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.

Thanks,
Leo

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