Skip to content

linux, linux-esx: make canister_build work against the current kernel - #1675

Open
dcasota wants to merge 2 commits into
vmware:5.0from
dcasota:fix/canister-build-against-current-kernel
Open

dcasota wants to merge 2 commits into
vmware:5.0from
dcasota:fix/canister-build-against-current-kernel

Conversation

@dcasota

@dcasota dcasota commented Sep 1, 2026

Copy link
Copy Markdown
Contributor

Problem

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.

1 out of 2 hunks FAILED -- crypto/rsa-pkcs1pad.c.rej

Upstream dropped the WARN_ON() wrapper around !digest_size in pkcs1pad_verify(). That single line is shared context for canister-creation patches 1004 and 1010, so at --fuzz=0 both fail to apply.

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. Every section laid out after .bss was numbered one too high and its relocations were reversed against the wrong section, so the reconstructed image no longer matched the recorded HMAC. This stayed invisible for as long as the compiler happened to emit .bss after every measured section.

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 flips fips back to 1 after its architecture block and pulls in canister machinery that cannot work there: the canister is arch/x86 crypto, and both the generator and the kernel-side interpreter handle 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.

Change

Rebase patches 1004 and 1010 onto the current source. In 1004 the WARN_ONfcw_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.

Let only a measured section consume a section 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; only the numbering handed to the interpreter changes.

Confine the acvp_build override to x86_64, so fips stays 0 on aarch64. And refuse acvp_build and kat_build on any other architecture, with the same block in SPECS/linux/linux.spec and SPECS/90/linux/linux.spec, so the build stops at once and says why. They are refused rather than switched off: Photon's SpecParser.py cannot undefine a macro the build injected, so it would still compute an .acvp Release that rpm no longer builds. canister_build stays allowed on aarch64, where it is already ignored.

On x86_64 both specs preprocess identically apart from the new comment, and SpecParser.py computes the same name, sources and patches for every architecture and toggle.

Based on #24 / #1673: the canister_config.inc change merges first, this one follows as 6.12.109-3.

🤖 Generated with Claude Code

@dcasota
dcasota force-pushed the fix/canister-build-against-current-kernel branch 2 times, most recently from 5167f6a to 2110644 Compare September 2, 2026 08:10
@aabusair aabusair closed this Sep 2, 2026
@aabusair aabusair reopened this Sep 2, 2026
@dcasota
dcasota force-pushed the fix/canister-build-against-current-kernel branch 6 times, most recently from 94ccc61 to c4a4e52 Compare September 9, 2026 11:19
@dcasota
dcasota force-pushed the fix/canister-build-against-current-kernel branch 5 times, most recently from 632de3c to 2994258 Compare September 13, 2026 05:18
dcasota and others added 2 commits September 14, 2026 11:26
…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
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.

2 participants