search

espressif / esp-idf

Espressif IoT Development Framework. Official development framework for Espressif SoCs.
Apache License 2.0
13.37k stars 7.21k forks source link

ESP32-S3 - Combination Secure boot+Flash Encryption does not work (IDFGH-12855) #13821

Closed Crinst closed 3 months ago

Crinst commented 4 months ago

Answers checklist.

General issue report

I have submitted my question/issue on ESP32 forum: https://www.esp32.com/viewtopic.php?f=13&t=39891, but so far there was no reply so I'm forced to try it over here.

I would like to unable secure boot and flash encryption on ESP32-S3 in host-generated use-case so I can setup my product in controlled matter. As I wrote in topic on the forum, I have used this combination in the past on ESP32 (N16R8) without issue, but I'm unable to make it work for ESP32-S3 N16R18.

Could you please help me out? I'm pretty sure that I'm either missing something basic or there's bug in whole process. Thank you very much

SolidStateLEDLighting commented 4 months ago

I have been all through this process. For the S3, use version 2 of the security tools.

AdityaHPatwardhan commented 4 months ago

Hi @Crinst Looking at your logs. I can see that secure boot and flash encryption was enabled correctly and you were able to run the code successfully on the first boot up. It seems the issue is introduced afterwards which is causing a problem while booting up the same factory partition once again. It might be that for some reason the factory partition is getting changed and then it is failing the verification on the next boot, or could be other flash encryption related issue.

Crinst commented 4 months ago

Hi @Crinst Looking at your logs. I can see that secure boot and flash encryption was enabled correctly and you were able to run the code successfully on the first boot up. It seems the issue is introduced afterwards which is causing a problem while booting up the same factory partition once again. It might be that for some reason the factory partition is getting changed and then it is failing the verification on the next boot, or could be other flash encryption related issue.

Hi, yes, that's exactly what I found out, but based on "not good" guide and my previous experience on ESP32, I cannot find anything wrong in either sdkconfig or eFuses or elsewhere. So if anyone could give me a hint where to look for I fould be very happy.

AdityaHPatwardhan commented 4 months ago

@Crinst, I will try to reproduce the issue at my end. It is not likely a straightforward issue that can be fixed by changing the eFuses.

I am assuming that a newly flashed firmware still works on the first boot before reset. As the flash encryption and secure boot workflow in the bootloader executed successfully I dont think there is any issue with the eFuses. You may verify this by adding the https://github.com/espressif/esp-idf/blob/4523f2d67465373f0e732a3264273a8e84a1a6d1/components/bootloader_support/include/esp_flash_encrypt.h#L199 and https://github.com/espressif/esp-idf/blob/4523f2d67465373f0e732a3264273a8e84a1a6d1/components/bootloader_support/include/esp_secure_boot.h#L324 in your firmware that shall be executed on the first boot. This shall confirm flash encryption and secure boot related eFuse conditions

If possible, can you try flashing an application that is built on the latest release i.e. v5.2.1? The flash_encryption example should do the trick. It might be possible that some issue was fixed in later releases but was not back ported. This shall give us a better idea.

Can you please let me know which IDF commit that you are using from release/v4.4 ? I saw a version in your logs but it seems 5 months old so I wanted to confirm.

Additionally can you please elaborate any problems that you face for the guide being not good ? FYI we fixed the host-based workflows document recently but it shall take time for it to be a part of stable release. You can view the newest version here

Additionally, I read in your message that you applied some fixes to esp-idf. Can you please confirm that no changes are related to flash encryption or any hardware peripheral that is related.

Crinst commented 4 months ago

@Crinst, I will try to reproduce the issue at my end. It is not likely a straightforward issue that can be fixed by changing the eFuses.

I am assuming that a newly flashed firmware still works on the first boot before reset. As the flash encryption and secure boot workflow in the bootloader executed successfully I dont think there is any issue with the eFuses. You may verify this by adding the

https://github.com/espressif/esp-idf/blob/4523f2d67465373f0e732a3264273a8e84a1a6d1/components/bootloader_support/include/esp_flash_encrypt.h#L199

and https://github.com/espressif/esp-idf/blob/4523f2d67465373f0e732a3264273a8e84a1a6d1/components/bootloader_support/include/esp_secure_boot.h#L324

in your firmware that shall be executed on the first boot. This shall confirm flash encryption and secure boot related eFuse conditions If possible, can you try flashing an application that is built on the latest release i.e. v5.2.1? The flash_encryption example should do the trick. It might be possible that some issue was fixed in later releases but was not back ported. This shall give us a better idea.

Can you please let me know which IDF commit that you are using from release/v4.4 ? I saw a version in your logs but it seems 5 months old so I wanted to confirm.

Additionally can you please elaborate any problems that you face for the guide being not good ? FYI we fixed the host-based workflows document recently but it shall take time for it to be a part of stable release. You can view the newest version here

Additionally, I read in your message that you applied some fixes to esp-idf. Can you please confirm that no changes are related to flash encryption or any hardware peripheral that is related.

Hi,

1) the functions to check secure boot and flash encryption are non-existent in my esp idf so I'm unable to validate these, but console logs showed valid outputs during first boot so I assume that eFuses and configuration should be fine.

2) I will try to validate with newer esp-idf version, but I wanted to keep as long as possible my validated version v4.4 as it provided consistent results and I know that all possible bugs are known and fixed. Anyway I will try flash_encryption example just to be sure.

3) Yes, its correct. I had to reinstall whole build machine few months back so I downloaded current version from Git with ESP-IDF VSCode extension. Based on the console command "git log" I have received this response (older commits were not copied into this commend). I hope its what you are looking for.

commit ddc44956bf718540d5451e17e1becf6c7dffe5b8 (HEAD -> release/v4.4, origin/release/v4.4) commit ddc44956bf718540d5451e17e1becf6c7dffe5b8 (HEAD -> release/v4.4, origin/release/v4.4) Merge: f952b9f71b 997040222d Author: Anton Maklakov anton@espressif.com Date: Fri Nov 19 14:35:01 2021 +0000

Merge branch 'bugfix/esp32s3_esp_timer_test_failure_v4.4' into 'release/v4.4'

examples: esp_timer: disable secondary console for S3/C3 that can affect test timing (v4.4)

See merge request espressif/esp-idf!16021

commit 997040222d25a6e33d09ae53b103335290ffb960 Author: Mahavir Jain mahavir@espressif.com Date: Fri Nov 12 17:27:07 2021 +0530

examples: esp_timer: disable secondary console for S3/C3 that can affect test timing

4) Regarding the guide, there is no "complete guide" or at least somehow comment about correct procedure for combination of secure boot and flash encryption, which I assume will be the most used security combination. On top of that, in "Enable Flash Encryption Externally" in point 5B, you suggest write_protect_efuse DIS_ICACHE, which does not make any sense (probably picked wrong line. In document https://github.com/espressif/esp-idf/blob/master/components/efuse/esp32c3/esp_efuse_table.csv one line higher is RD_DIS, which would make way more sense). I cannot remember all issue, which I had encountered but there were more efuse names, which were different between mentioned csv table and guides steps, but I somehow found correct ones... I'm pretty sure that based on these missing informations and errors in guide, inexperienced person woundn't be able to successfuly enable security features.

5) I have only make some changed to Modbus library as I did not produce expected results for my application. It does not have any connection with security.

AdityaHPatwardhan commented 4 months ago

@Crinst,

  1. I will try to validate with newer esp-idf version, but I wanted to keep as long as possible my validated version v4.4 as it provided consistent results and I know that all possible bugs are known and fixed. Anyway I will try flash_encryption example just to be sure.

Yes please do test it on v5.2.1, You may keep using the older v4.4.x version for your project if you wish to but just that the testing on v5.2.1 might give us some more insights.

Regarding the guide, there is no "complete guide" or at least somehow comment about correct procedure for combination of secure boot and flash encryption, which I assume will be the most used security combination. On top of that, in "Enable Flash Encryption Externally" in point 5B, you suggest write_protect_efuse DIS_ICACHE, which does not make any sense (probably picked wrong line. In document https://github.com/espressif/esp-idf/blob/master/components/efuse/esp32c3/esp_efuse_table.csv one line higher is RD_DIS, which would make way more sense). I cannot remember all issue, which I had encountered but there were more efuse names, which were different between mentioned csv table and guides steps, but I somehow found correct ones... I'm pretty sure that based on these missing informations and errors in guide, inexperienced person wouldn't be able to successfully enable security features.

Did you check https://docs.espressif.com/projects/esp-idf/en/latest/esp32c3/security/host-based-security-workflows.html#enable-flash-encryption-and-secure-boot-v2-externally, It offers all the necessary configurations for enabling secure boot and flash encryption correctly. Please let me know why you think it's incomplete. There are 2 methods to enable flash encryption and secure boot. One is using the default way that is the esp-idf bootloader and the other is using external tools as explained in the document. Both workflows correctly enable flash encryption and secure boot. I assume you followed the same steps to enable flash encryption and secure boot. If you had to modify any step in the workflow because it was not working then can you please share the modified step and the reasoning ? I would be happy to make the respective change in the document.

Regarding DIS_ICACHE, If you check the DIS_ICACHE eFuse. It disables the ICACHE for the device. this is flexibility offered to the user. But when you enable secure boot and flash encryption using ICACHE becomes mandatory hence it is important to write disable the ICACHE field so that it is not accidentally disabled by the user. As mentioned in the note below it also enables write protection for additional eFuses since they share the same write disable bit.

commit https://github.com/espressif/esp-idf/commit/ddc44956bf718540d5451e17e1becf6c7dffe5b8 (HEAD -> release/v4.4, origin/release/v4.4)

Okay so I'll assume that this is the IDF version that you are using and it has not been updated to the latest version of release/v4.4. I recommend that you should update to the latest version of release/v4.4 branch. Since it's the same branch no breaking changes would be present and the update should be seamless.

AdityaHPatwardhan commented 3 months ago

@Crinst, Did you find time to check the above things. If not can you at least try to check reproducing the issue on the latest commit of release/v4.4 ? Please let me know if you are able to reproduce

Crinst commented 3 months ago

@Crinst, Did you find time to check the above things. If not can you at least try to check reproducing the issue on the latest commit of release/v4.4 ? Please let me know if you are able to reproduce

Hi @AdityaHPatwardhan,

I have updated my ESP-IDF to latest version of release\4.4 branch (v4.4.7 right now) and It helped a lot. It compiled correctly and finally validated application image after restart. I have tried OTA update as well and it worked flawlesly. So It seems pulling latest changes did the trick and so far there are not issues with ESP32-S3.

From what I can see, older "versions" of v4.4 are not fully compatible with ESP32-S3, it worked fine for ESP32. Maybe you could add some notes to security guide about need for update fo these older releases in order to be fully compatible.

Thank you very much for you help and assistance. It really helped a lot.

AdityaHPatwardhan commented 3 months ago

Hi @Crinst Its good to know that your issue has been fixed. Actually it is recommended to use only the latest bug fix releases for product development. If you are using a release branch for faster availability of fixes then you must make sure that you are using the latest version.

We already have a note in the security documentation regarding that.

I will go ahead and close the issue, please feel to re-open if required. Thanks, Aditya