Message-ID: <20260203074853-7e380585-f7d6-47e7-94b1-cf16bbfb7a08@linutronix.de>
Date: Tue, 3 Feb 2026 08:01:55 +0100
From: Thomas Weißschuh <thomas.weissschuh@...utronix.de>
To: Naman Jain <namjain@...ux.microsoft.com>
Cc: Nathan Chancellor <nathan@...nel.org>, Nicolas Schier <nsc@...nel.org>, 
	Catalin Marinas <catalin.marinas@....com>, Will Deacon <will@...nel.org>, Andy Lutomirski <luto@...nel.org>, 
	Thomas Gleixner <tglx@...nel.org>, Ingo Molnar <mingo@...hat.com>, Borislav Petkov <bp@...en8.de>, 
	Dave Hansen <dave.hansen@...ux.intel.com>, x86@...nel.org, "H . Peter Anvin" <hpa@...or.com>, 
	Masahiro Yamada <masahiroy@...nel.org>, Miguel Ojeda <ojeda@...nel.org>, 
	Tamir Duberstein <tamird@...il.com>, Steven Rostedt <rostedt@...dmis.org>, 
	Kees Cook <kees@...nel.org>, Ard Biesheuvel <ardb@...nel.org>, linux-kbuild@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-arm-kernel@...ts.infradead.org, 
	Saurabh Singh Sengar <ssengar@...ux.microsoft.com>
Subject: Re: [RFC PATCH] kbuild: Make --build-id linker flag configurable

On Tue, Feb 03, 2026 at 11:58:11AM +0530, Naman Jain wrote:
> On 2/2/2026 7:45 PM, Thomas Weißschuh wrote:
> > Hi Naman,
> > 
> > On Mon, Feb 02, 2026 at 11:06:31AM +0000, Naman Jain wrote:
> > > Build ID hashes include file paths, so building the same source from
> > > different directories produces different binaries. This breaks
> > > reproducible builds.
> > > 
> > > Add KBUILD_BUILD_ID variable (default: sha1) to allow overriding:
> > > 
> > >      make KBUILD_BUILD_ID=none
> > > 
> > > The variable is exported to VDSO Makefiles which also include a
> > > fallback default for standalone invocation.
> > > 
> > > Signed-off-by: Naman Jain <namjain@...ux.microsoft.com>
> > > ---
> > > Hi,
> > > Sending this change for RFC, as it is quite possible that this is a
> > > generic problem and I may be missing something.
> > > 
> > > I am trying to implement reproducible builds for one of my product
> > > kernel. I referred https://reproducible-builds.org/docs/build-path/
> > > and tried to use both -fdebug-prefix-map=OLD=NEW and
> > > -fmacro-prefix-map=OLD=NEW, but still could not achieve bit by bit
> > > binary reproducibility without overwriting build-id to none.
> > > If I move the kernel to same path in other setup, I was able to create
> > > same binary hash, however, without it, there is some difference in
> > > build-id hash values.
> > 
> 
> Hi Thomas,
> Thanks for looking into this and sharing your inputs.
> 
> 
> > Can you force the same build path during package building?
> > That should avoid this issue.
> 
> Since we can't control where the user would clone their kernel, I was
> initially skeptical to copy the kernel to a same build path like
> /tmp/kernel/src directory due to uncertainties related to free space,
> permissions, but I tried it now and it works fine. It should be OK for my
> use-case.
> 
> I am currently using NixOS for reproducible build environment.

So users are already forced to use a specific distribution for rebuilding.
Also requiring a specific build path doesn't look like a big step then.

> > > Reproducibility wiki says "In most cases however, post-processing is
> > > required to either remove the build path or to normalize it to a
> > > predefined value.". I have tried that, and it works, but wanted to
> > > conclude if that is my last option here.
> > 
> > I am not a fan of this aproach. The build id should stay usable.
> > Can you figure out where the build paths are used?
> > You may need to also compare the debug symbols.
> > 
> > > Thanks.
> 
> I agree.
> We did not have any use of these build paths, but some vendors may be using
> it to fetch the build information from the binaries.
> If your comment was about in-kernel usage of these build paths, I'll look
> into it.

I'd like to know where the build paths in the binary are coming from.
So we can fix the issue properly instead of working around it.
You said you are using -fmacro-prefix-map and -fdebug-prefix-map to avoid them.
(There is also -ffile-prefix-map which should be more robust and easy to use)

> > > ---
> > >   Makefile                          | 8 ++++++--
> > >   arch/arm64/kernel/vdso/Makefile   | 5 ++++-
> > >   arch/arm64/kernel/vdso32/Makefile | 5 ++++-
> > >   arch/x86/entry/vdso/Makefile      | 5 ++++-
> > >   4 files changed, 18 insertions(+), 5 deletions(-)
> > > 
> > > diff --git a/Makefile b/Makefile
> > > index 3373308d2217c..3fcff4af200d7 100644
> > > --- a/Makefile
> > > +++ b/Makefile
> > > @@ -1132,8 +1132,12 @@ KBUILD_AFLAGS   += $(KAFLAGS)
> > >   KBUILD_CFLAGS   += $(KCFLAGS)
> > >   KBUILD_RUSTFLAGS += $(KRUSTFLAGS)
> > > -KBUILD_LDFLAGS_MODULE += --build-id=sha1
> > > -LDFLAGS_vmlinux += --build-id=sha1
> > > +# Can be overridden for reproducible builds by using "make KBUILD_BUILD_ID=none"
> > > +KBUILD_BUILD_ID ?= sha1
> > > +export KBUILD_BUILD_ID
> > > +
> > > +KBUILD_LDFLAGS_MODULE += --build-id=$(KBUILD_BUILD_ID)
> > > +LDFLAGS_vmlinux += --build-id=$(KBUILD_BUILD_ID)
> > >   KBUILD_LDFLAGS	+= -z noexecstack
> > >   ifeq ($(CONFIG_LD_IS_BFD),y)
> > > diff --git a/arch/arm64/kernel/vdso/Makefile b/arch/arm64/kernel/vdso/Makefile
> > > index 7dec05dd33b70..b3ee5982b4676 100644
> > > --- a/arch/arm64/kernel/vdso/Makefile
> > > +++ b/arch/arm64/kernel/vdso/Makefile
> > > @@ -9,6 +9,9 @@
> > >   # Include the generic Makefile to check the built vdso.
> > >   include $(srctree)/lib/vdso/Makefile.include
> > > +# Fallback for standalone builds, normally inherited from top-level Makefile
> > > +KBUILD_BUILD_ID ?= sha1
> > > +
> > 
> > What kind of standalone builds?
> > This doesn't look like it belongs into this patch.
> > 
> > (...)
> 
> The case I was trying to cover here was when we try to compile
> arch/x86/entry/vdso/ separately, without the KBUILD_BUILD_ID coming from
> main build scripts, "--build-id=" would be left empty, while we may want to
> retain original value i.e. sha1.
> 
>     make ARCH=x86_64 arch/x86/entry/vdso/

I don't think this is or should be supported.

> arch/x86/entry/vdso/Makefile:
> -VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 --no-undefined \
> +VDSO_LDFLAGS = -shared --hash-style=both --build-id=$(KBUILD_BUILD_ID)
> --no-undefined \
> 
> Anyways, this may not be required now.


Thomas

Powered by blists - more mailing lists