linux: fix canister reverse-relocation section numbering

[dcasota]

Problem

A kernel that links a locally built FIPS canister panics at 0.64 s:

FIPS(fips_integrity_init): canister 6.12 found (based on 6.12.109-4.ph5)
FIPS(fips_integrity_init): processing 8 sections, 687696 bytes
Kernel panic - not syncing: FIPS canister verification failed!
   fips_integrity_check+0x1a1/0x2e8

The canister that ships with the distribution (6.12.60-18.2) still verifies, so FIPS boot as such is fine. Only canisters built from current sources fail — which is what canister_build=1 produces.

Root cause

gen_canister_relocs gives each section an ondx, the index fips_integrity_init() uses to address its si[] array when reversing a relocation:

r->section = section_symbols[sndx]->ondx;   /* gen_canister_relocs.c:292 */
pc  = si[r->section].saddr + offset;        /* fips_integrity.c:349 */

si[] is built from canister_sections[], which by construction holds only sections carrying both markers:

if (section_symbols[i] && section_symbols[i]->end)   /* gen_canister_relocs.c:430 */

.bss carries a begin marker only — it is deliberately not measured, it exists in the list purely so relocations can resolve against it — yet it still consumed an ondx. Every section laid out after .bss was therefore numbered one too high, and its relocations were reversed against the wrong section's buffer. The reconstructed image then no longer matched the HMAC recorded at build time.

This stayed invisible for as long as .bss happened to be emitted after every measured section. gcc 12.2 did exactly that; gcc 12.5 (5fce7ef, 92: core-toolchain: upgrade gcc to 12.5 and binutils to 2.46.1) does not:

	section order (ondx 0…)
gcc 12.2	.text .init.text .exit.text .rodata .smp_locks .data .init.data .bss .init.rodata
gcc 12.5	.rodata .text .data .bss .init.text .exit.text .smp_locks .init.data .init.rodata

Under the new layout .init.text, .exit.text, .smp_locks and .init.data — 568 relocations — are all misdirected, and ondx reaches 8 on an eight-entry si[].

.init.rodata was already numbered one too high under gcc 12.2 as well. It never mattered because it carries zero relocations, in both the passing and the failing canister.

Fix

Only a section that is actually measured may consume an index. .bss cannot hold relocations (it is NOBITS), so the sentinel is never dereferenced.

The measured set, the generated linker script and therefore the canister HMAC are all unchanged — running the old and the new generator over the same object produces a byte-identical canister_markers.lds and an identical canister_sections_size. Only the numbering handed to the interpreter changes.

Evidence

Established from build artefacts, without rebuilding:

• The compiler is the trigger. The last canister that verified reports GCC: (GNU) 12.2.0 in .comment; the first that failed reports GCC: (GNU) 12.5.0. Same kernel source version on both sides of the boundary, so the kernel version is not the variable.
• The build side is correct. Recomputing the build-time measurement from each shipped fips_canister.o — objcopy --only-section per section in linker-script order, concatenated, HMAC-SHA256 — reproduces the injected digest exactly, for the passing and the failing canister alike.
• The linker is correct. Every byte that differs between the canister object and the same region in the linked vmlinux is covered by a relocation in that section; there are zero uncovered differences across all eight measured sections. Nothing beyond relocation application touches the canister.

That leaves the reverse-relocation step, and the numbering above accounts for it.

section	size	differing vs vmlinux	relocs	uncovered
.text	249367	14105	3974	0
.init.text	6264	1475	378	0
.exit.text	1510	385	100	0
.rodata	345384	33975	4278	0
.smp_locks	8	8	2	0
.data	39976	2081	262	0
.init.data	704	702	88	0
.init.rodata	44483	0	0	0

Testing

check_spec.py passes; the generator compiles clean with -Wall.

End-to-end confirmation requires a canister build plus a relinked kernel booted with fips=1, which is running separately; this PR is posted on the strength of the artefact analysis above rather than waiting on it.

Note on certification

A canister built this way is functionally correct but not CMVP-validated — the published 6.12.60-18.2 cannot certify a 6.12.109 kernel, and nothing built locally certifies anything. This fix is about a locally built canister being correct, which is what the boot-time integrity check demands regardless of certification.

🤖 Generated with Claude Code

[dcasota]

Folded into #29, which carries the same change as 6.12.109-4. Keeping it separate would have collided with #24 and #29 on the linux.spec Release line, and it belongs with them in any case: a canister that builds but is rejected at boot is the same defect this series addresses.