[RFC PATCH] kbuild: Make --build-id linker flag configurable

Thomas Weißschuh thomas.weissschuh at linutronix.de
Mon Feb 2 06:15:30 PST 2026


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 at linux.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.

Can you force the same build path during package building?
That should avoid this issue.

> 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.
> 
> ---
>  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.

(...)



More information about the linux-arm-kernel mailing list