[dgarske]

Description

A zeroize destroys the image encryption key, so until now the golden recovery image had to be stored in plaintext to stay bootable. That does not suit deployments whose data-at-rest requirement covers the recovery image too.

DISK_GOLDEN_ENCRYPT_KEY=1 gives the golden slot a key of its own, in a second sNVM module that the failover never erases. The zeroize still destroys the operational key in module 201, so the operational images become undecryptable while the golden image stays encrypted at rest and bootable. Both keys are wrapped by the same device PUF KEK - the separation is only which module gets erased, so wolfBoot_erase_encrypt_key() is unchanged and the zeroize itself needs no new code.

SNVM_GOLDEN_ENCKEY_MODULE has no default and must be set. It has to name a plaintext sNVM client the Libero design both configures and leaves writable: a page marked ROM cannot be written, and a page never configured as a client cannot even be read, so the provisioning writer's pre-read refuses it. Both failures are silent until a device is in hand, so the build requires an explicit choice rather than guessing. MPFS_SNVM_DUMP reports the state of a candidate page.

The platform selects a slot's key with wolfBoot_select_golden_encrypt_key(). There is deliberately no default implementation: a target that cannot select a key fails to link rather than reading the golden image under the operational one. Provisioning the second key is its own knob, SNVM_GOLDEN_ENCKEY_PROVISION, because the zeroize that makes a second key worth having cannot be built alongside a provisioning run. The option is off by default, and with it off the generated binary is unchanged.

For integrators: a golden bitstream that carries sNVM clients should carry the golden key module only. Carrying module 201 as well restores the operational key when the bitstream is reapplied, which partially undoes the zeroize.

Testing

Host unit tests in tools/unit-tests/unit-update-disk-golden-enckey.c cover the golden image booting after the operational key is zeroized, the operational key being the only one erased, and two fail-closed cases: the golden key missing, and a golden image encrypted under the operational key. unit-snvm-kek-golden builds the real sNVM provider with both keys and checks the selector, that the erase takes the operational page even with golden selected, and that golden still unwraps afterwards. The existing disk-boot and failover suites are unchanged.

Exercised on a PolarFire SoC MPFS250TS Video Kit. The refusal path is confirmed on silicon: provisioning a page the Libero design does not configure as a writable plaintext client fails closed rather than writing it. The positive end-to-end case is not yet covered on hardware, because the Video Kit's stock design leaves no spare sNVM client for a second key, and an encrypted golden image on the card needs host-side card access.

[Copilot]

🟡 Changes recommended

Conflicting zeroize and provisioning guards make the documented golden-key provisioning build impossible.

4 open issues

• Allow provisioning-only builds to use the two-key layout · New
• Test real two-key selection and golden-page preservation · New
• Forward the golden-key module override to the compiler · New
• Keep key installation out of the mock getter · New

What changed in this PR

This PR adds an optional, separate encryption key for the PolarFire SoC golden recovery image, allowing it to remain encrypted and bootable after the operational key is zeroized.

Changes:

• Adds per-slot key selection and a separate sNVM module for the golden key.
• Adds host tests for encrypted recovery and fail-closed behavior.
• Documents configuration, provisioning, and bitstream requirements.

File	Description
tools/​unit-tests/​unit-update-disk-golden-enckey.c	Adds encrypted golden-slot boot and failure tests.
tools/​unit-tests/​Makefile	Registers and builds the new test suite.
src/​update_disk.c	Rekeys the disk cipher for the selected slot.
options.mk	Adds the option and prerequisite checks.
include/​wolfboot/​wolfboot.h	Declares the platform key-selection API.
hal/​mpfs250_snvm.h	Defines and validates the golden-key module.
hal/​mpfs250_snvm.c	Implements key selection and two-key provisioning.
docs/​PolarFire.md	Documents encrypted recovery and provisioning constraints.
docs/​encrypted_partitions.md	Links to the encrypted golden-image guidance.
config/​examples/​polarfire_mpfs250_m.config	Adds a commented configuration example.

_{Review effort: Balanced}