-
Notifications
You must be signed in to change notification settings - Fork 852
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
ESP32-XX: fix hardware flash encryption issue when updating images #2320
Conversation
64ec4e9 to
cd51774
Compare
cd51774 to
b3b01c5
Compare
b3b01c5 to
c31bf4e
Compare
3eb4366 to
8ef9137
Compare
|
@utzig @marekmatej could you please take a look? |
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>
0d74f6d to
7de5e82
Compare
|
@d3zd3z could you please take a look? It's missing a codeowner review. |
|
@de-nordic or @nvlsianpu would you mind to take a look on this, please? It's pending a review of someone with write access on the repository. |
gustavonihei
left a comment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
PR looks good, just found some minor nitpicks.
… 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>
7de5e82 to
0686764
Compare
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.overlayBuilding and flashing MCUboot:
(MCUBOOT_DIR should be the directory from Zephyr environment:
<ZEPHYRPROJECT_DIR>/bootloader/mcuboot)<MCUBOOT_DIR>/boot/espressif/port/esp32s3/bootloader.confwith: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
0xFFs binary file and flash it to the regions in order to avoid an unexpected behavior:Upload the update image through wifi using
smpmgr:smpmgrcommand. Connect the device to wifi again, fetch the image information and use its hash to confirm the image.