Cherry-pick to earlgrey_es_sival: [rom_ext, ownership] Fix the flash region configuration #26126
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
Ownership flash lockdown was protecting and locking all regions in the same slot that booted the owner code. However, the ROM_EXT and owner code don't have to boot from the same side of the flash. 1. Disallow ownership configurations that have flash regions that overlap with the ROM_EXT region. It is an error to upload such a configuration, but if one already exists in the chip, the owner-specified ROM_EXT regions are ignored in favor of the self-protection. 2. Always protect the ROM_EXT by using flash regions 0 and 1. 3. Update ownership tests. 4. Update SiVAL tests that used flash MP regions 0 & 1, as the ROM_EXT now uses them. Fixes lowRISC#25435. Signed-off-by: Chris Frantz <cfrantz@google.com> (cherry picked from commit d28f9e4)
cfrantz
requested review from
timothytrippel
and removed request for
a team and
timothytrippel
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 <cfrantz@google.com> (cherry picked from commit 9be96dc)
cfrantz
force-pushed
the
rom_ext-flash-lock
branch
from
a532468 to
19e0c14
Compare
moidx
approved these changes
Feb 5, 2025
| if ((hardened_bool_t)config->rescue != kHardenedBoolFalse) | ||
| return kErrorOwnershipDuplicateItem; | ||
| config->rescue = (const owner_rescue_config_t *)item; | ||
| if (check_only == kHardenedBoolFalse) { |
There was a problem hiding this comment.
Probably a good idea to merge this PR before I merge the ISFB changes. That way I can add the check_only condition.
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.
This is a manual cherry-pick of #26014 and #26077 back to
earlgrey_es_sival.