From: bruce.ashfield@gmail.com
To: richard.purdie@linuxfoundation.org
Cc: openembedded-core@lists.openembedded.org
Subject: [PATCH 2/2] linux-yocto/7.2: fix kernel reproducibility issues
Date: Tue, 22 Sep 2026 23:40:34 -0400 [thread overview]
Message-ID: <20260923034034.729674-2-bruce.ashfield@gmail.com> (raw)
In-Reply-To: <20260923034034.729674-1-bruce.ashfield@gmail.com>
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
prev parent reply other threads:[~2026-09-23 3:40 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-23 3:40 [PATCH 1/2] linux-yocto/6.18: fix kernel reproducibility issues bruce.ashfield
2026-09-23 3:40 ` bruce.ashfield [this message]
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260923034034.729674-2-bruce.ashfield@gmail.com \
--to=bruce.ashfield@gmail.com \
--cc=openembedded-core@lists.openembedded.org \
--cc=richard.purdie@linuxfoundation.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox