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

[dcasota]

The problem

canister_build=1 fails in %prep against Photon 5.0's own current kernel. The canister-creation series is maintained against the certified kernel 6.12.60, and upstream has since dropped the WARN_ON() wrapper around !digest_size in pkcs1pad_verify():

// 6.12.60 — what the series expects
if (WARN_ON(req->dst) || WARN_ON(!digest_size) ||
// 6.12.103 — what is actually there
if (WARN_ON(req->dst) || !digest_size ||

rpm applies at --fuzz=0, so pure context drift is fatal:

+ rpmuncompress .../1004-Move-__bug_table-section-to-fips_canister_wrapper.patch
+ /usr/bin/patch -p1 -s --fuzz=0 --no-backup-if-mismatch -f
1 out of 2 hunks FAILED -- saving rejects to file crypto/rsa-pkcs1pad.c.rej
error: Bad exit status from /var/tmp/rpm-tmp.2derUe (%prep)

It looks worse than it is

%prep stops at the first failure, so this reads like a diverged patch series. It is not. Applying 1000–1016 to the 6.12.103 tree and forcing through failures to see the whole picture:

16 of 18 applications succeed unmodified. The only two rejects are the same line, in the same function, in the same file — patch 1004 (which converts it) and patch 1010 (which carries it as context). With both hunks rebased, the series applies clean at --fuzz=0 with zero rejects.

Why 1004 matters beyond compiling

WARN_ON expands to a __bug_table entry, and 1004-Move-__bug_table-section-to-fips_canister_wrapper.patch exists specifically to keep __bug_table out of the canister. Leaving that call unconverted would embed a bug-table entry in the frozen blob.

Also: the version pins

Both canister version pins were bare %defines with no %{!?...} guard, so no build could be pointed at anything but the certified canister without editing the spec:

• fips_canister_version (both flavours) — so a build can link a canister produced locally for the kernel under test.
• fips_certified_kernel_version — so a build that creates a new canister can stamp the kernel it was really built from, rather than inherit a certification it does not carry. The spec's own comment already asked for this: "Remove below line when building a new canister."

linux-esx deliberately keeps canister_build 0. The canister is one artifact, built once and consumed by both flavours — which is exactly how the prebuilt path already works. Making the pin overridable is all that flavour needs.

Verification

• Default build unchanged: resolves fips-canister-6.12.60-18.2.ph5.tar.bz2 exactly as before, so a normal build is byte-identical.
• -D 'fips_canister_version 6.12.103-12.ph5' → both specs resolve the local canister.
• -D 'canister_build 1' → linux-fips-canister subpackage still emitted.
• Rebased series applies clean at --fuzz=0, verified from a true pre-series tree (original 1004 reverse-applied first, so the result is not an artefact of the partial application).

Not verified

A full canister kernel build has not completed — the rebase was validated at patch and spec level. The %build-stage struct comparator (check_kernel_struct_in_canister.inc) has not been exercised against 6.12.103.