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(-)
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@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.
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.
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
+
obj-vdso := vgettimeofday.o note.o sigreturn.o vgetrandom.o vgetrandom-chacha.o
# Build rules
@@ -22,7 +25,7 @@ btildflags-$(CONFIG_ARM64_BTI_KERNEL) += -z force-bti
# routines, as x86 does (see 6f121e548f83 ("x86, vdso: Reimplement vdso.so
# preparation in build-time C")).
ldflags-y := -shared -soname=linux-vdso.so.1 \
- -Bsymbolic --build-id=sha1 -n $(btildflags-y)
+ -Bsymbolic --build-id=$(KBUILD_BUILD_ID) -n $(btildflags-y)
ifdef CONFIG_LD_ORPHAN_WARN
ldflags-y += --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
diff --git a/arch/arm64/kernel/vdso32/Makefile b/arch/arm64/kernel/vdso32/Makefile
index 9d0efed91414c..991aed67e65a2 100644
--- a/arch/arm64/kernel/vdso32/Makefile
+++ b/arch/arm64/kernel/vdso32/Makefile
@@ -5,6 +5,9 @@
include $(srctree)/lib/vdso/Makefile.include
+# Fallback for standalone builds, normally inherited from top-level Makefile
+KBUILD_BUILD_ID ?= sha1
+
# Same as cc-*option, but using CC_COMPAT instead of CC
ifeq ($(CONFIG_CC_IS_CLANG), y)
CC_COMPAT ?= $(CC)
@@ -87,7 +90,7 @@ VDSO_AFLAGS += -D__ASSEMBLY__
# From arm vDSO Makefile
VDSO_LDFLAGS += -Bsymbolic --no-undefined -soname=linux-vdso.so.1
VDSO_LDFLAGS += -z max-page-size=4096 -z common-page-size=4096
-VDSO_LDFLAGS += -shared --build-id=sha1
+VDSO_LDFLAGS += -shared --build-id=$(KBUILD_BUILD_ID)
VDSO_LDFLAGS += --orphan-handling=$(CONFIG_LD_ORPHAN_WARN_LEVEL)
diff --git a/arch/x86/entry/vdso/Makefile b/arch/x86/entry/vdso/Makefile
index f247f5f5cb44d..fefddc91b41ea 100644
--- a/arch/x86/entry/vdso/Makefile
+++ b/arch/x86/entry/vdso/Makefile
@@ -6,6 +6,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
+
# Files to link into the vDSO:
vobjs-y := vdso-note.o vclock_gettime.o vgetcpu.o vgetrandom.o vgetrandom-chacha.o
vobjs32-y := vdso32/note.o vdso32/system_call.o vdso32/sigreturn.o
@@ -155,7 +158,7 @@ quiet_cmd_vdso = VDSO $@
$(VDSO_LDFLAGS) $(VDSO_LDFLAGS_$(filter %.lds,$(^F))) \
-T $(filter %.lds,$^) $(filter %.o,$^)
-VDSO_LDFLAGS = -shared --hash-style=both --build-id=sha1 --no-undefined \
+VDSO_LDFLAGS = -shared --hash-style=both --build-id=$(KBUILD_BUILD_ID) --no-undefined \
$(call ld-option, --eh-frame-hdr) -Bsymbolic -z noexecstack
quiet_cmd_vdso_and_check = VDSO $@
base-commit: 63804fed149a6750ffd28610c5c1c98cce6bd377
--
2.43.0Hi 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@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. (...)
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@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.
>
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.
>
>> 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.
>>
>> ---
>> 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/
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.
Regards,
Naman
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@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. > > > > 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
On 2/3/2026 12:31 PM, Thomas Weißschuh wrote: > 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@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. >>> >> >> 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. Ack. > >>>> 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) I was suspecting these are coming from linker scripts, in VDSO compilation but I could not pin-point to the real issue here. I will check more to find out what exactly is missing here. > >>>> --- >>>> 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. Ack. > >> 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 Regards, Naman
On Mon, Feb 02, 2026 at 03:15:30PM +0100, Thomas Weißschuh wrote: > On Mon, Feb 02, 2026 at 11:06:31AM +0000, Naman Jain wrote: > > 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. Yeah, I think that it would be better to document this in Documentation/kbuild/reproducible-builds.rst, as opposed to adding a hack to disable the build ID altogether. It seems easy enough to make the paths consistent between machines and environments by using a container or such. The new scripts/container in -next could help there. Cheers, Nathan
On 2/3/2026 4:45 AM, Nathan Chancellor wrote: > On Mon, Feb 02, 2026 at 03:15:30PM +0100, Thomas Weißschuh wrote: >> On Mon, Feb 02, 2026 at 11:06:31AM +0000, Naman Jain wrote: >>> 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. > > Yeah, I think that it would be better to document this in > Documentation/kbuild/reproducible-builds.rst, as opposed to adding a > hack to disable the build ID altogether. It seems easy enough to make > the paths consistent between machines and environments by using a > container or such. The new scripts/container in -next could help there. > > Cheers, > Nathan Thank you Nathan for your inputs. I'll plan to ensure same path for my kernel build, and send a patch to add this in reproducible builds documentation. --- a/Documentation/kbuild/reproducible-builds.rst +++ b/Documentation/kbuild/reproducible-builds.rst @@ -58,6 +58,9 @@ to an absolute filename in an out-of-tree build. Kbuild automatically uses the ``-fmacro-prefix-map`` option to prevent this, if it is supported. +If it still does not work, ensure that the kernel is built in the same +directory, using containers or such. + The Reproducible Builds web site has more information about these `prefix-map options`_. Regards, Naman
© 2016 - 2026 Red Hat, Inc.