Conversation
dcasota
force-pushed
the
fix/kernel-shared-canister-config
branch
5 times, most recently
from
September 9, 2026 11:16
1e115b3 to
a9e54a7
Compare
dcasota
force-pushed
the
fix/kernel-shared-canister-config
branch
2 times, most recently
from
September 11, 2026 19:25
d28f018 to
495763b
Compare
dcasota
force-pushed
the
fix/kernel-shared-canister-config
branch
from
September 13, 2026 04:50
495763b to
fadc19e
Compare
This was referenced Sep 13, 2026
dcasota
force-pushed
the
fix/kernel-shared-canister-config
branch
from
September 14, 2026 09:28
fadc19e to
dee805a
Compare
dcasota
force-pushed
the
fix/kernel-shared-canister-config
branch
5 times, most recently
from
September 19, 2026 11:44
aeda1ed to
af278c2
Compare
dcasota
force-pushed
the
fix/kernel-shared-canister-config
branch
2 times, most recently
from
September 30, 2026 04:00
635f42c to
ab1963f
Compare
…g.inc
linux.spec and linux-esx.spec implemented the same canister Kconfig handling
in two different idioms, and they disagreed on one constellation.
linux-esx.spec used %if 0%{?fips} / %else, and its %else branch cleaned the
GCC_PLUGIN_{MATCH,PAD}_CANISTER_STRUCTS comments out of .config. linux.spec
instead used two independent %if canister_build / %if canister_usage blocks
with no %else, so when fips=0 nothing ran: the shipped .config kept the
"is not set" comments, make olddefconfig dropped them, and the
check_for_config_applicability.inc diff guard failed %prep. That is an
x86_64 kernel built without the canister: fips is set by %global inside
%ifarch, so it is 1 on x86_64 unless that line is edited to 0, and
config_x86_64 carries both "is not set" comments. The aarch64 configs
never carried them.
Move the three conditional blocks into SPECS/linux/canister_config.inc,
pulled in by both specs as Source5 + %include, the same mechanism both
already use for check_for_config_applicability.inc. Divergence between the
two flavours is now impossible by construction.
linux-esx.spec additionally gains the derived-flag block linux.spec already
had (canister_build=0, canister_usage=fips), nested inside the existing
%if fips so it does not shadow -D. esx never builds a canister - it untars a
prebuilt one - so fips=1 implies canister_usage=1, reproducing the old
branch exactly.
Tested across 112 cells: 2 specs x {x86_64, aarch64} x subrelease {91, 92} x
14 flag combinations of fips / canister_build / canister_usage / acvp_build /
kat_build. All x86_64 cells are byte-identical apart from the release string.
The aarch64 fips=0 cells replace PR#14's broad sed with linux-esx's narrower
pair; the two forms produce byte-identical output on all five shipped config
files, because no config contains a CANISTER_STRUCTS=y form - only the
"is not set" comment form. The esx aarch64 reordering is likewise a no-op:
the canister and jitterentropy seds touch disjoint symbols.
Change-Id: If4107c14d8f15752dff0c0f25c6b4dee504e3041
Signed-off-by: Daniel Casota <dcasota@gmail.com>
dcasota
force-pushed
the
fix/kernel-shared-canister-config
branch
from
September 30, 2026 11:49
ab1963f to
23eeef2
Compare
This branch has not been deployed
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
SPECS/linux/linux.specandSPECS/linux/linux-esx.speceach carry their own copy of the FIPS canister Kconfig handling, and the two copies are not identical:linux.spechas nofips=0branch.Building x86_64 without the canister —
fipsset to 0 — therefore leaves the# CONFIG_GCC_PLUGIN_MATCH_CANISTER_STRUCTS is not setand# CONFIG_GCC_PLUGIN_PAD_CANISTER_STRUCTS is not setlines ofconfig_x86_64in.config. Those symbols exist only once the canister plugin patches have been applied, somake olddefconfigsilently drops them and thecheck_for_config_applicability.incdiff guard fails%prep.linux-esx.spechas the missing branch and passes. The aarch64 configs never carried those lines.Change
Move the handling into a single
SPECS/linux/canister_config.inc, added asSource5and%included by both flavours. It covers the three cases in one place:canister_build,canister_usageandfips=0.The default x86_64 FIPS builds keep the
.configthey had. What is new is thefips=0cleanup inlinux.spec, and that the two flavours can no longer diverge here.🤖 Generated with Claude Code