Skip to content

linux, linux-esx: share the canister/.config logic via canister_config.inc - #24

Open
dcasota wants to merge 1 commit into
5.0from
fix/kernel-shared-canister-config
Open

dcasota wants to merge 1 commit into
5.0from
fix/kernel-shared-canister-config

Conversation

@dcasota

@dcasota dcasota commented Aug 31, 2026

Copy link
Copy Markdown
Owner

Problem

SPECS/linux/linux.spec and SPECS/linux/linux-esx.spec each carry their own copy of the FIPS canister Kconfig handling, and the two copies are not identical: linux.spec has no fips=0 branch.

Building x86_64 without the canister — fips set to 0 — therefore leaves the # CONFIG_GCC_PLUGIN_MATCH_CANISTER_STRUCTS is not set and # CONFIG_GCC_PLUGIN_PAD_CANISTER_STRUCTS is not set lines of config_x86_64 in .config. Those symbols exist only once the canister plugin patches have been applied, so make olddefconfig silently drops them and the check_for_config_applicability.inc diff guard fails %prep. linux-esx.spec has 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 as Source5 and %included by both flavours. It covers the three cases in one place: canister_build, canister_usage and fips=0.

The default x86_64 FIPS builds keep the .config they had. What is new is the fips=0 cleanup in linux.spec, and that the two flavours can no longer diverge here.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JW73JTCUGRcaNTUEQcAMtf

@dcasota

dcasota commented Aug 31, 2026

Copy link
Copy Markdown
Owner Author

Rebased onto the updated 5.0 head (a8dcfa34b), which moved both kernel specs.

A real defect the update introduced, now fixed. Upstream bumped linux-esx.spec to Release 11 while this PR still set it to 10 — that would have been a downgrade. Resolved:

spec upstream now this PR
linux.spec 10 (CVE-2026-68082) 11
linux-esx.spec 11 (CVE-2026-68082), 10 (CRX regression) 12

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 5.0 base has no fips=0 handling in linux.spec at all — so this PR is now the sole carrier of that fix, not a pure refactor. The linux.spec changelog entry was reworded accordingly; linux-esx.spec remains behaviour-preserving, since it always handled fips=0 correctly in its %else.

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}:

spec result
linux.spec 12/16 SAME; 4 DIFFER — the aarch64 fips=0 cells (default and canister_build=1), where the base emits nothing and this PR emits delMATCH delPAD. That difference is the fix.
linux-esx.spec 16/16 SAME

All x86_64 cells unchanged on both specs; the aarch64 acvp/kat cells are unchanged because those flags force fips=1.

support/spec-checker/check_spec.py exits 0 on both specs.

@dcasota
dcasota force-pushed the fix/kernel-shared-canister-config branch 5 times, most recently from 7ba215f to 1e115b3 Compare September 7, 2026 12:13
@dcasota
dcasota force-pushed the fix/kernel-shared-canister-config branch from 1e115b3 to a9e54a7 Compare September 9, 2026 11:16
@dcasota
dcasota force-pushed the fix/kernel-shared-canister-config branch 2 times, most recently from d28f018 to 495763b Compare September 11, 2026 19:25
@dcasota
dcasota force-pushed the fix/kernel-shared-canister-config branch from 495763b to fadc19e Compare September 13, 2026 04:50
…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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant