ESP32 Forum

Hi,

I am trying to make a more a complex SSBL that would parse X.509 certificates and verify RSA signatures. However I am facing issues with the size of the bootloader. I am using the bootloader_override example as a base.

I have stripped the mbedtls to bare minimum to be able to parse x509 certificates and I am considering using the ROM code from hal component for RSA-PSS signature verification, however even so I am getting the following results: According to the bootloader guide in the ESP32-S3:

Set CONFIG_PARTITION_TABLE_OFFSET to a higher value than 0x8000, to place the partition table later in the flash. This increases the space available for the bootloader.
When Secure Boot V2 is enabled, there is also an absolute binary size limit of 64 KB (0x10000 bytes) (excluding the 4 KB signature), because the bootloader is first loaded into a fixed size buffer for verification.

With this in mind I've changed the partition offset from 0x8000 (32k) to 0x10000 (64k) in the sdkconfig using menuconfig: However, I am still getting a linker error because the bootloader does not fit in 32k: Running idf_size.py on the bootloader map still yields the same values above. I am confused about the 32kb memory limitation, it seems it comes from two separate places - partition offset and IRAM. Accorting to the ESP32-S3 Technical Reference (page 399, Table 4-1. Internal Memory Address Mapping) the instruction buss accessible RAM (IRAM) seems to be 32kb (SRAM0) + 416kb (SRAM1).

Why I cannot change the partition offset and get larger bootloader (SSBL) size?

Kind regards,
Marin

I don't think that is a size issue. The issue seems more that you/your code seems to use dynamic allocation (malloc() and friends) and I don't think this is available in the bootloader.

Thank you for your reply.
You seem to be right.

I am wondering what is limiting the SSBL to have dynamic memory allocation?

I am trying to use a very stripped down version of mbedTLS, to enable X.509 certificate parsing and RSA signature verification. I am trying to make as little changes to the algorithms, since they are already verified. Fitting the stripped-down library in the SSBL is one of the challenges, but trying to keep the code as close to the original adds more to it.

What would be your proposal to handle this?
Is there a easier way to replace the libc memory allocator, or should I just use an arena allocator and replace the functions within the stripped mbledTLS librbary and the x509 component that is allocating dynamic memory?


PS. I am sorry that it took me so much time to reply. I have forgotten to tick "Notify me when a reply is posted".

Kind regards.
Marin

metala wrote: ↑

Fri May 17, 2024 11:20 am

I am wondering what is limiting the SSBL to have dynamic memory allocation?

Theoretically nothing, but as bootloaders generally shouldn't be updated, we try to keep them as small as possible to have the lowest possible attack and bug surface.