Conversation
e2fac59 to
13c506d
Compare
|
Rebased onto the updated A real defect the update introduced, now fixed. Upstream bumped
Upstream's changelog entries are preserved in both; mine sit on top. The framing changed too, and the changelog now says so. With #14 closed unmerged, the new Re-verified against the new base — the earlier proof no longer covered it, since upstream changed both specs. Matrix over arch {x86_64, aarch64} × subrelease {91, 92} × {default, canister_build=1, acvp_build=1, kat_build=1}:
All x86_64 cells unchanged on both specs; the aarch64
|
7ba215f to
1e115b3
Compare
1e115b3 to
a9e54a7
Compare
d28f018 to
495763b
Compare
495763b to
fadc19e
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>
fadc19e to
dee805a
Compare
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
https://claude.ai/code/session_01JW73JTCUGRcaNTUEQcAMtf