initrd: Consume signed fwupd capsules

[Sean-StarLabs]

Draft / RFC

Add a board-gated path for consuming firmware staged by fwupd in EFI/UpdateCapsule. The consumer validates the EFI capsule, exact package contents, board and capsule GUID, generation, ROM size and hash, and a detached signature from an isolated vendor keyring before calling a board-selected writer.

Rejected requests are quarantined. Accepted requests are renamed to .applying before the writer runs and removed only after a successful write.

Add an independent TPM2 QEMU fixture with a disposable public key, mock file-backed writer, and stable SMBIOS identity. Physical boards remain disabled.

Runtime validation

• Booted the exact committed QEMU ROM under QEMU/TCG with swtpm and a FAT ESP containing a signed capsule with a full 16 MiB firmware payload.
• Observed the mock writer accept the payload and the consumer remove the capsule after success.
• Exercised the host functional suite: valid capsule accepted; oversized capsule, rollback, wrong signed GUID, wrong board, tampered signature, wrong header GUID, and malformed header rejected.

WIP follow-up

This is based directly on current linuxboot/heads master and has no dependency on the Star Labs board series.

Production enablement still requires per-board capsule GUIDs, embedded production public keys, monotonic generation policy, physical flash writers, a persistent completion/failure result contract, and protected-flash hardware validation.

Companion fwupd Draft PR: fwupd/fwupd#10910.

[tlaurion]

CC @pietrushnic @macpijan (feel free to ping proper internal resource for review)

[SergiiDmytruk]

Interesting idea to make fwupd pass a capsule to Heads, but given custom payload format (tar archive with a few files), I'm not sure that wrapping it as a capsule achieves much. Yet it still appears as UEFI-related and requires uefi-capsule plugin of fwupd with its dependencies.

In this form it won't be shared with UEFI firmware and LVFS can distribute non-capsule firmware just the same, so I would be interested to know how this approach was selected. Or are you planning to reuse the same format for EDK2 as well?

[tlaurion]

Interesting idea to make fwupd pass a capsule to Heads, but given custom payload format (tar archive with a few files), I'm not sure that wrapping it as a capsule achieves much. Yet it still appears as UEFI-related and requires uefi-capsule plugin of fwupd with its dependencies.

In this form it won't be shared with UEFI firmware and LVFS can distribute non-capsule firmware just the same, so I would be interested to know how this approach was selected. Or are you planning to reuse the same format for EDK2 as well?

cc @Sean-StarLabs

[Sean-StarLabs]

I would be interested to know how this approach was selected.

Well, 100% untested, so we'll see how it pans out but theory was:

• fwupd can already do it (heads plugin would be... complex)
• could be loaded into a branch, so people can switch from edk2 to heads (likely impossible to switch back)
• capsules already contain the rmaps
• capsules are signed so maybe can write via smm