Repository navigation
Conversation
Contributor
There was a problem hiding this comment.
🟡 Changes recommended
Conflicting zeroize and provisioning guards make the documented golden-key provisioning build impossible.
4 open issues
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
Comment on lines
+204
to
+207
| ifneq ($(DISK_GOLDEN_SLOT)$(SNVM_KEK)$(DISK_FAILOVER_ZEROIZE),111) | ||
| $(error DISK_GOLDEN_ENCRYPT_KEY=1 requires DISK_GOLDEN_SLOT=1, SNVM_KEK=1 \ | ||
| and DISK_FAILOVER_ZEROIZE=1: a second key exists so the zeroize can \ | ||
| destroy one and leave the other) |
Comment on lines
+431
to
+432
| snvm_enckey_module = golden ? SNVM_GOLDEN_ENCKEY_MODULE : | ||
| SNVM_ENCKEY_MODULE; |
| and DISK_FAILOVER_ZEROIZE=1: a second key exists so the zeroize can \ | ||
| destroy one and leave the other) | ||
| endif | ||
| CFLAGS+=-D"DISK_GOLDEN_ENCRYPT_KEY" |
Comment on lines
+212
to
+213
| mock_cur_key = mock_pending_key; | ||
| memset(key, mock_cur_key, ENCRYPT_KEY_SIZE); |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
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=1gives the golden slot a key of its own, in a second sNVM module (default 202) 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, sowolfBoot_erase_encrypt_key()is unchanged and the zeroize itself needs no new code.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. 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 module 202 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.ccover 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. The existing disk-boot and failover suites are unchanged, and the PolarFire config matrix gains a row for the new option.