-
Notifications
You must be signed in to change notification settings - Fork 818
ESP32-XX: fix hardware flash encryption issue when updating images #2320
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
almir-okato
wants to merge
7
commits into
mcu-tools:main
Choose a base branch
from
almir-okato:fix_esp_mcuboot_flash_enc_flash_imp_layer
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
ESP32-XX: fix hardware flash encryption issue when updating images #2320
almir-okato
wants to merge
7
commits into
mcu-tools:main
from
almir-okato:fix_esp_mcuboot_flash_enc_flash_imp_layer
+631
−61
Conversation
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
64ec4e9
to
cd51774
Compare
cd51774
to
b3b01c5
Compare
b3b01c5
to
c31bf4e
Compare
3eb4366
to
8ef9137
Compare
@utzig @marekmatej could you please take a look? |
sylvioalves
reviewed
Aug 28, 2025
sylvioalves
reviewed
Aug 28, 2025
sylvioalves
reviewed
Aug 28, 2025
sylvioalves
reviewed
Aug 28, 2025
sylvioalves
reviewed
Aug 28, 2025
sylvioalves
reviewed
Aug 28, 2025
Also fix build if hal_espressif is used as IDF code layer (hal) for Espressif Port Signed-off-by: Almir Okato <almir.okato@espressif.com>
Signed-off-by: Almir Okato <almir.okato@espressif.com>
Signed-off-by: Almir Okato <almir.okato@espressif.com>
Signed-off-by: Almir Okato <almir.okato@espressif.com>
Add cache flush after write/erase operations to avoid getting invalid data when these are followed by read operation. Signed-off-by: Almir Okato <almir.okato@espressif.com>
… encryption is enabled When hardware flash encryption is enabled, force expected erased value (0xFF) into flash when erasing a region, and also always do a real erase before writing data into flash. This is handled on this implementation because MCUboot's state machine relies on erased valued data (0xFF) readed from a previously erased region that was not written yet, however when hardware flash encryption is enabled, the flash read always decrypts whats being read from flash, thus a region that was erased would not be read as what MCUboot expected (0xFF). Signed-off-by: Almir Okato <almir.okato@espressif.com>
Refactor force aligned write and erase algorithms to improve readability. Signed-off-by: Almir Okato <almir.okato@espressif.com>
0d74f6d
to
7de5e82
Compare
sylvioalves
approved these changes
Sep 15, 2025
sylvioalves
reviewed
Sep 15, 2025
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.
When hardware flash encryption is enabled, force expected erased value (0xFF) into flash when erasing a region, and also always do a real erase before writing data into flash.
This is handled on this implementation because MCUboot's state machine relies on erased valued data (0xFF) readed from a previously erased region that was not written yet, however when hardware flash encryption is enabled, the flash read always decrypts whats being read from flash, thus a region that was erased would not be read as what MCUboot expected (0xFF).
This PR also bumps used IDF code version to v5.1.6.
How to test it within Zephyr on ESP32-S3 using a "zeroed" key (DEVELOPMENT AND TEST ONLY, so the device will not be bricked) and updating through Wi-Fi:
Use Zephyr branch from this PR:
zephyrproject-rtos/zephyr#90442 (already merged into Zephyr's
main
)Use hal_espressif branch from this PR:
zephyrproject-rtos/hal_espressif#478 (already merged into hal_espressif's
main
)Prepare and enable Flash Encryption on ESP32-S3:
Building the SMPMGR sample application on Zephyr:
<ZEPHYRPROJECT_DIR>/zephyr/samples/subsys/mgmt/mcumgr/smp_svr/boards/esp32s3_devkitm_procpu.overlay
Building and flashing MCUboot:
(MCUBOOT_DIR should be the directory from Zephyr environment:
<ZEPHYRPROJECT_DIR>/bootloader/mcuboot
)<MCUBOOT_DIR>/boot/espressif/port/esp32s3/bootloader.conf
with:Workaround for empty slot1 and scratch regions when testing:
Testing like described, as Flash Encryption would be already enabled, reading an empty region (physical 0xFF values) would result in garbage as the read decryption would decrypt the data unconditionally. So generate a
0xFF
s binary file and flash it to the regions in order to avoid an unexpected behavior:Upload the update image through wifi using
smpmgr
:smpmgr
command. Connect the device to wifi again, fetch the image information and use its hash to confirm the image.