Conversation
…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>
Two defects keep canister_build=1 from producing a usable canister, and a third lets the FIPS build modes run where they cannot work. 1. The patch series no longer applies. Upstream dropped the WARN_ON() wrapper around !digest_size in pkcs1pad_verify(), and that single line is shared context for canister-creation patches 1004 and 1010, so %prep fails at --fuzz=0 with 1 out of 2 hunks FAILED -- crypto/rsa-pkcs1pad.c.rej Rebase both onto the 6.12 series. In 1004 the WARN_ON -> fcw_warn_on conversion is load-bearing rather than cosmetic: WARN_ON emits a __bug_table entry, and keeping __bug_table out of the canister is what that patch exists to do. 2. A canister that does build is rejected at boot: FIPS(fips_integrity_init): processing 8 sections, 687696 bytes Kernel panic - not syncing: FIPS canister verification failed! gen_canister_relocs gives each section an "ondx", the number fips_integrity_init() uses to index its si[] array when reversing a relocation. si[] is built from canister_sections[], which holds only the sections carrying both markers. .bss carries a begin marker only - it is not measured, it is listed so relocations can resolve against it - yet it still consumed an ondx, so every section laid out after .bss was numbered one too high and its relocations were reversed against the wrong section. Let only a measured section consume an index. .bss is NOBITS and cannot hold relocations, so the sentinel is never dereferenced. The measured set, the generated linker script and the canister HMAC are unchanged. 3. acvp_build and kat_build build x86_64 inputs on other architectures. The build system injects both toggles for every architecture. On aarch64, SPECS/linux/linux.spec re-enabled fips after its architecture block and pulled in canister machinery that cannot work there: the canister is arch/x86 crypto and its tooling handles only R_X86_64_* relocations. Independently, in SPECS/linux/linux.spec and SPECS/90/linux/linux.spec alike, acvp_build selects config_x86_64_acvp, the only ACVP config, for an arm64 kernel, and the build fails late for a reason that names neither toggle. Confine the fips override to x86_64, and refuse acvp_build and kat_build on any other architecture with the same block in both specs, so the build stops at once and says why. They are refused rather than undefined because Photon's SpecParser.py cannot undefine an injected macro, and would still compute a .acvp Release that rpm no longer builds. canister_build stays allowed on aarch64, where it is already ignored. Change-Id: Ib5878beeec1dd79e2bcdfefc33639d2b40d69d14 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JW73JTCUGRcaNTUEQcAMtf
SPECS/linux/linux.spec and linux-esx.spec now build kernel 6.1 for photon_subrelease 90 and below and kernel 6.12 from 91, on x86_64 and aarch64, replacing SPECS/90/linux/linux.spec and linux-esx.spec. Each kernel's preamble (Release, FIPS model, sources, patches) and changelog live in <flavour>-<kernel>.inc and <flavour>-<kernel>-changelog.inc; linux.spec also takes the subpackages whose descriptions differ from linux-<kernel>-packages.inc. Version, Source0, the dependencies both kernels share, the acvp/kat refusal and every section are written once, with photon_subrelease conditionals where the kernels differ. The 6.1 files move to SPECS/linux: included files to the top level, where SpecParser resolves includes, everything else under 6.1/. A name that exists for 6.12 with other content gets a -6.1 suffix, because Photon stages sources by file name. The 6.1 archives join config.yaml. linux-rt stays in SPECS/90/linux with the files it uses. rpm and Photon's SpecParser read both specs exactly as before for subreleases 90, 91 and 92, on x86_64 and aarch64, with and without canister_build, acvp_build and kat_build. check_spec needs fix/check-spec-subrelease-aware on the common branch to read a spec that serves several subreleases. Change-Id: Iee86a86f800b0bb70b83b96c673078a4bc6e1512 Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JW73JTCUGRcaNTUEQcAMtf
This was referenced Sep 15, 2026
dcasota
added a commit
to dcasota/photonos-scripts
that referenced
this pull request
Sep 15, 2026
Upstream ee3c2b78b (92/linux CVE fixes) took linux and linux-esx to 6.12.109-2, the release the canister PR stack had used. The stack was rebased: linux and linux-esx to -3, the canister_build fix to -4, and the single-source specs regenerated on top. Until the permutation rows pass, the variants cherry-pick the rebased stack from the fork-only branch test/kernel-single-source-rebase-20260915 instead of fix/kernel-single-source, which still backs vmware/photon#1680. The embedded canister-equivalent patch is regenerated against it and now takes linux to 6.12.109-5 and linux-esx to -4. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01JW73JTCUGRcaNTUEQcAMtf
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
1 participant
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
Photon 5.0 keeps two copies of each kernel spec:
SPECS/90/linux/linux.specandlinux-esx.specbuild kernel 6.1 forphoton_subrelease90 and below,SPECS/linux/builds 6.12 from 91. Every change that is not kernel-specific — dependencies, sections, the canister logic, the acvp/kat refusal — has to be made twice, and the two copies drift.Change
SPECS/linux/linux.specandlinux-esx.specnow build every 5.0 subrelease, on x86_64 and aarch64, and replaceSPECS/90/linux/linux.specandlinux-esx.spec.Version, Source0, the dependencies both kernels share, the acvp/kat refusal and every section are written once, with
photon_subreleaseconditionals where the kernels differ. Each kernel's preamble (Release, FIPS model, sources, patches) and changelog live in<flavour>-<kernel>.incand<flavour>-<kernel>-changelog.inc;linux.specalso takes the subpackages whose descriptions differ fromlinux-<kernel>-packages.inc.The 6.1 files move to
SPECS/linux: included files to the top level, whereSpecParser.pyresolves includes, everything else under6.1/. A name that already exists for 6.12 with other content gets a-6.1suffix, because Photon stages sources by file name. The 6.1 archives joinconfig.yaml.linux-rtstays inSPECS/90/linuxwith the files it uses.Testing
rpmspec -P, preamble and queries) and Photon'sSpecParser.pyread both specs exactly as before for subreleases 90, 91 and 92, on x86_64 and aarch64, with and withoutcanister_build,acvp_buildandkat_build: 48 cases plus kernel selection and source mapping, all identical.%prepand preprocessed spec); no aarch64 build host was available.Dependencies
check_specneeds spec-checker: check a spec as the subrelease being checked sees it #1678 to read a spec that serves several subreleases.make imageneeds spec-generator: read kernel specs as the current subrelease sees them #1679: the kernel-deps generator otherwise crashes on the single spec.🤖 Generated with Claude Code