[rom_ext, ownership] Fix the flash region configuration #26077
Merged
Conversation
This file contains 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
cfrantz
force-pushed
the
a1-rom_ext-protect
branch
from
dfef607 to
d34904e
Compare
jettr
reviewed
Jan 31, 2025
cfrantz
force-pushed
the
a1-rom_ext-protect
branch
from
d34904e to
0c2d6ba
Compare
jettr
approved these changes
Jan 31, 2025
moidx
approved these changes
Feb 3, 2025
| lock = kHardenedBoolFalse; | ||
| } | ||
|
|
||
| if (*mp_index < 2 * FLASH_CONFIG_REGIONS_PER_SLOT) { |
There was a problem hiding this comment.
Is this the MP layout you have in mind? It would be good to capture it in an md doc so that we can provide it as a reference. I am seeing some questions from integration teams.
| MP Slot | Description |
|---|---|
| 0 | ROM_EXT slot A |
| 1 | ROM_EXT slot B |
| 2 | Owner Slot A - Entry 0 |
| 3 | Owner Slot A - Entry 1 |
| 4 | Owner Slot A - Entry 2 |
| 5 | Owner Slot B - Entry 0 |
| 6 | Owner Slot B - Entry 1 |
| 7 | Owner Slot B - Entry 2 |
There was a problem hiding this comment.
Correct: in the LockedOwner state, SlotA entries are programmed into MP_REGION registers first, then SlotB entries.
In the unlocked states (UnlockedAny, UnlockedEndorsed), current_owner's entries are programmed first (for whichever side is primary), then next_owner's entries are programmed (for whichever side is secondary). This ordering was chosen to keep current_owner's firmware booting in the primary slot and to allow next_owner to program their image into the secondary slot and then attempt a boot with a SetBl0Next command.
I did not write correct test cases that would check a flash configuration similar to the owner config already deployed in some skus. This oversight could cause ownership initialization to fail on devies with such a configuration. 1. Permit a maximum of 3 regions per side in the flash configuration. The regions must be fully within the bounds of SlotA or SlotB and may not overlap the ROM_EXT region. 2. Apply the region configuration in order. Previously, there was a correspondence between the index of the region in the owner config and the MP_REGION register that it would land in, but this makes ownership transfers prone to configuration clashes. 3. Flash configuration is done in two passes to configure each side independently (the reason for this is to allow next_owner's flash config to apply to the non-primary side during ownership transfer). The flash_apply function now takex an index parameter to manage the desination MP_REGION register between passes. 4. Create a unittest case with a flash configuration similar to the already-deployed configuration. Include the ROM_EXT, application, filesystem and reserved segments. 5. Update the existing test cases to accomodate the new configuration scheme (e.g. applying in order rather than by index). Signed-off-by: Chris Frantz <[email protected]>
cfrantz
force-pushed
the
a1-rom_ext-protect
branch
from
0c2d6ba to
9be96dc
Compare
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.
I did not write correct test cases that would check a flash configuration similar to the owner config already deployed in some skus. This oversight could cause ownership initialization to fail on devies with such a configuration.
first_passparameter to theflash_applyfunction to allow managing the internal state.Fixes #25435.