[PATCH 1/2] linux-yocto/6.18: fix kernel reproducibility issues

[PATCH 1/2] linux-yocto/6.18: fix kernel reproducibility issues

[bruce.ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Integrating the following commit(s) to linux-yocto/6.18:

1/1 [
    Author: Bruce Ashfield
    Email: bruce.ashfield@gmail.com
    Subject: x86/Kconfig.cpu: pin CC_HAS_MARCH_NATIVE off for reproducible builds
    Date: Tue, 22 Sep 2026 21:50:19 -0400

    CONFIG_CC_HAS_MARCH_NATIVE is a def_bool computed from
    $(cc-option, -march=native), i.e. it is probed from the build-host
    compiler. In cross builds the result varies by build host: the kernel's
    own comment already notes "This flag might not be available in
    cross-compilers" So it is captured differently across otherwise
    identical builds and breaks kernel package reproducibility:

      .config / auto.conf:  CONFIG_CC_HAS_MARCH_NATIVE=y   (host A) vs absent (host B)
      autoconf.h:           #define CONFIG_CC_HAS_MARCH_NATIVE 1
      .config:              # CONFIG_X86_NATIVE_CPU is not set
      rustc_cfg:            --cfg=CONFIG_CC_HAS_MARCH_NATIVE

    With CONFIG_IKCONFIG=y the .config is gzip-embedded into the kernel
    (kernel_config_data), so the difference also propagates into
    vmlinux/bzImage/kernel-dbg (the blob shifts kernel_config_data_end and
    every symbol after it), failing reproducibility across the whole kernel
    package set. Not just the config text files, which is why a post-package
    filter is not sufficient.

    CC_HAS_MARCH_NATIVE protects only X86_NATIVE_CPU ("build and optimize
    for local/native CPU"), which is never enabled in these builds and
    is not something we should do in a distributed/reproducible
    kernel. Pin the symbol off so the captured config is deterministic
    regardless of build host. On-target 'make scripts prepare' uses
    this same patched Kconfig, so it recomputes the same value and
    needs no reconfiguration.

    Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---
 .../linux/linux-yocto-rt_6.18.bb              |  4 ++--
 .../linux/linux-yocto-tiny_6.18.bb            |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_6.18.bb | 20 +++++++++----------
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb b/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb
index 31a0294070..03487e9f4a 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.18.bb
@@ -15,8 +15,8 @@ python () {
         raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "c191bb993af1f71ef139504fcce530a9ba167a0d"
-SRCREV_meta ?= "9e9d8b1f9128b07d938b8b7d5921aeb3ddf907a1"
+SRCREV_machine ?= "a23529ae3d1aa70979a3399f370638f3086587e3"
+SRCREV_meta ?= "2184786cc3deed04926e1cca6c320ed9314da9da"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.18;destsuffix=${KMETA};protocol=https"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb
index 1b7575be0c..d2bd34732f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.18.bb
@@ -18,8 +18,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
-SRCREV_meta ?= "9e9d8b1f9128b07d938b8b7d5921aeb3ddf907a1"
+SRCREV_machine ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
+SRCREV_meta ?= "2184786cc3deed04926e1cca6c320ed9314da9da"
 
 PV = "${LINUX_VERSION}+git"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.18.bb b/meta/recipes-kernel/linux/linux-yocto_6.18.bb
index 055a2d39dd..3008f1751f 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.18.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.18.bb
@@ -17,18 +17,18 @@ KBRANCH:qemux86-64 ?= "v6.18/standard/base"
 KBRANCH:qemuloongarch64  ?= "v6.18/standard/base"
 KBRANCH:qemumips64 ?= "v6.18/standard/mti-malta"
 
-SRCREV_machine:qemuarm ?= "4932d76684b2bc2cbf8dc6e0e46ada17ad020c71"
-SRCREV_machine:qemuarm64 ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
-SRCREV_machine:qemuloongarch64 ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
+SRCREV_machine:qemuarm ?= "49ec63d52f864d8cece5c6caa6be446362478003"
+SRCREV_machine:qemuarm64 ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
+SRCREV_machine:qemuloongarch64 ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
 SRCREV_machine:qemumips ?= "62ea92a539f58803a222be98b81118403074206e"
-SRCREV_machine:qemuppc ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
-SRCREV_machine:qemuriscv64 ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
-SRCREV_machine:qemuriscv32 ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
-SRCREV_machine:qemux86 ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
-SRCREV_machine:qemux86-64 ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
+SRCREV_machine:qemuppc ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
+SRCREV_machine:qemuriscv64 ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
+SRCREV_machine:qemuriscv32 ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
+SRCREV_machine:qemux86 ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
+SRCREV_machine:qemux86-64 ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
 SRCREV_machine:qemumips64 ?= "9fb4ff0187c85426f21fd40d4c61b742800f65c4"
-SRCREV_machine ?= "08edce0ecd6a36020447f51f11329b6641d3c0e2"
-SRCREV_meta ?= "9e9d8b1f9128b07d938b8b7d5921aeb3ddf907a1"
+SRCREV_machine ?= "364c4b44ab2dcc7dfff16076522b62827bcb0e7d"
+SRCREV_meta ?= "2184786cc3deed04926e1cca6c320ed9314da9da"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll
 # get the <version>/base branch, which is pure upstream -stable, and the same
-- 
2.43.0

[PATCH 2/2] linux-yocto/7.2: fix kernel reproducibility issues

[bruce.ashfield]

From: Bruce Ashfield <bruce.ashfield@gmail.com>

Integrating the following commit(s) to linux-yocto/7.2:

1/1 [
    Author: Bruce Ashfield
    Email: bruce.ashfield@gmail.com
    Subject: x86/Kconfig.cpu: pin CC_HAS_MARCH_NATIVE off for reproducible builds
    Date: Tue, 22 Sep 2026 14:26:03 -0400

    CONFIG_CC_HAS_MARCH_NATIVE is a def_bool computed from
    $(cc-option, -march=native), i.e. it is probed from the build-host
    compiler. In cross builds the result varies by build host: the kernel's
    own comment already notes "This flag might not be available in
    cross-compilers" So it is captured differently across otherwise
    identical builds and breaks kernel package reproducibility:

      .config / auto.conf:  CONFIG_CC_HAS_MARCH_NATIVE=y   (host A) vs absent (host B)
      autoconf.h:           #define CONFIG_CC_HAS_MARCH_NATIVE 1
      .config:              # CONFIG_X86_NATIVE_CPU is not set
      rustc_cfg:            --cfg=CONFIG_CC_HAS_MARCH_NATIVE

    With CONFIG_IKCONFIG=y the .config is gzip-embedded into the kernel
    (kernel_config_data), so the difference also propagates into
    vmlinux/bzImage/kernel-dbg (the blob shifts kernel_config_data_end and
    every symbol after it), failing reproducibility across the whole kernel
    package set. Not just the config text files, which is why a post-package
    filter is not sufficient.

    CC_HAS_MARCH_NATIVE protects only X86_NATIVE_CPU ("build and optimize
    for local/native CPU"), which is never enabled in these builds and
    is not something we should do in a distributed/reproducible
    kernel. Pin the symbol off so the captured config is deterministic
    regardless of build host. On-target 'make scripts prepare' uses
    this same patched Kconfig, so it recomputes the same value and
    needs no reconfiguration.

    Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
]

Signed-off-by: Bruce Ashfield <bruce.ashfield@gmail.com>
---

This and the 6.18 fix are the same. You can see the details in the
commit message I captured above.

There's no generic/general solution at the moment, since we can't
drop the problematic values from the .config without changing
timestamps and then having the kernel just regenerate the configs.

We could probably dance around the timestamps for a bit and we'd
fix half the problem, but the .config compiled into the binary would
mean we'd also have to do the timestap fixes all through the build
and it has proven fragile in the past.

I checked this by grepping for the symbols between different builds
and they looked good.

The true test is the AB, so hopefully it holds there as well.

Bruce


.../linux/linux-yocto-rt_7.2.bb               |  4 ++--
 .../linux/linux-yocto-tiny_7.2.bb             |  4 ++--
 meta/recipes-kernel/linux/linux-yocto_7.2.bb  | 20 +++++++++----------
 3 files changed, 14 insertions(+), 14 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb b/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb
index 438c896749..e8e6c885ca 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_7.2.bb
@@ -15,8 +15,8 @@ python () {
         raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "c2f967f4c1065d41084f300d3eca7cd413635dc3"
-SRCREV_meta ?= "b5d69636e3e56aa6a5b8f987b4587e7a56c4782a"
+SRCREV_machine ?= "c3c2a26425ad13ed7d2bee0ff6f11365564bb33d"
+SRCREV_meta ?= "242eecdf2cb368016f92ad5317702b20f71d8c1e"
 
 SRC_URI = "git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https \
            git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-7.2;destsuffix=${KMETA};protocol=https"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb b/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb
index 0a9595a749..fe2666b86d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_7.2.bb
@@ -18,8 +18,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_meta ?= "b5d69636e3e56aa6a5b8f987b4587e7a56c4782a"
+SRCREV_machine ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_meta ?= "242eecdf2cb368016f92ad5317702b20f71d8c1e"
 
 PV = "${LINUX_VERSION}+git"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_7.2.bb b/meta/recipes-kernel/linux/linux-yocto_7.2.bb
index f1c2d475c1..55326a647b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_7.2.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_7.2.bb
@@ -17,18 +17,18 @@ KBRANCH:qemux86-64 ?= "v7.2/standard/base"
 KBRANCH:qemuloongarch64  ?= "v7.2/standard/base"
 KBRANCH:qemumips64 ?= "v7.2/standard/mti-malta"
 
-SRCREV_machine:qemuarm ?= "56c7106647e505ca1fb15fd433b0bc991024764c"
-SRCREV_machine:qemuarm64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemuloongarch64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
+SRCREV_machine:qemuarm ?= "3b075480e3eb36dbdbb7459ceb8220e30c168f7f"
+SRCREV_machine:qemuarm64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemuloongarch64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
 SRCREV_machine:qemumips ?= "ab0e33fefa2a3d0366b2b8deb7cfb3be2d8dc436"
-SRCREV_machine:qemuppc ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemuriscv64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemuriscv32 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemux86 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_machine:qemux86-64 ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
+SRCREV_machine:qemuppc ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemuriscv64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemuriscv32 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemux86 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_machine:qemux86-64 ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
 SRCREV_machine:qemumips64 ?= "ab0e33fefa2a3d0366b2b8deb7cfb3be2d8dc436"
-SRCREV_machine ?= "d8a1ec518ab72fadb60dbe9eed3775b68975defd"
-SRCREV_meta ?= "b5d69636e3e56aa6a5b8f987b4587e7a56c4782a"
+SRCREV_machine ?= "2ebaf2d45071d568d23e6570811bd63fb7cde633"
+SRCREV_meta ?= "242eecdf2cb368016f92ad5317702b20f71d8c1e"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and you'll
 # get the <version>/base branch, which is pure upstream -stable, and the same
-- 
2.43.0