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

[dcasota]

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_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.

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 / vmware#1673: the canister_config.inc change merges first, this one follows as 6.12.109-3.

🤖 Generated with Claude Code

https://claude.ai/code/session_01JW73JTCUGRcaNTUEQcAMtf