I see in
https://docs.espressif.com/projects/esp ... ot-v2.html
"The bootloader and application images are padded to the next 4096 byte boundary"
But in my builds it appears that images are padded to 64 KB boundaries, for example, from build log:
Signed 1179648 bytes of data from xxx-unsigned.bin
or
Signed 1245184 bytes of data from xxx-unsigned.bin
So, this "padded to the next 4096 byte boundary" statement in the doc is wrong?
I see up to 64 KB worth of 0-s appended to my xxx-unsigned.bin
And then another 4 KB of signature block is appended to make xxx.bin
So, the signed image xxx.bin has size = N*64 KB + 4096
But application partitions must be aligned on 64 KB address, therefore 60KB after the signature is wasted.
So, I have up to 64 KB + 60 KB wasted per app partition and this is repeated for all 3 partitions (Factory, OTA1, OTA2).
So it looks like total waste if (64 KB + 60 KB)*3 == 372 KB !
This is almost 10% of entire flash wasted on padding!
This must be wrong.
Please, tell me I am wrong.
And how to eliminate this totally needless padding?
I am aware of CONFIG_SECURE_BOOT_ALLOW_SHORT_APP_PARTITION, which does reduces padding,
but CONFIG_SECURE_BOOT_ALLOW_SHORT_APP_PARTITION is said to be insecure?
"It is generally not recommended to set this option, unless you have a legacy partitioning scheme which doesn’t support 64KB aligned partition lengths."
Note: my partition table is aligned:
factory, app, factory, 0x010000, 0x120000,
ota_0, app, ota_0, 0x130000, 0x150000,
ota_1, app, ota_1, 0x280000, 0x150000,
So, I accept wasting up to 64KB per partition,
but I cannot accept wasting second 64KB on the signature block.
In other words, can we keep secure 64KB padded partitions, but embed signature block within that 64 KB, not append to it, like it is done now.
Thank you
Why so much padding?
-
- Posts: 190
- Joined: Wed Jan 24, 2018 6:51 am
Re: Why so much padding?
Hello @jhnlmn,
Sorry for delayed reply!
Secure signed images have additional "padding" argument as highlighted below:
https://github.com/espressif/esp-idf/bl ... .cmake#L36
This padding in case of secure boot v2 scheme is done such that signature sector (variable length based on number of appended signature of each 1216 bytes) ends up on 64K aligned boundary. This allows to exclude signature sector from last mapped 64K MMU page and thus helps to avoid any untrusted data from signature sector mapped in instruction space.
Hope this helps!
Sorry for delayed reply!
Secure signed images have additional "padding" argument as highlighted below:
https://github.com/espressif/esp-idf/bl ... .cmake#L36
This padding in case of secure boot v2 scheme is done such that signature sector (variable length based on number of appended signature of each 1216 bytes) ends up on 64K aligned boundary. This allows to exclude signature sector from last mapped 64K MMU page and thus helps to avoid any untrusted data from signature sector mapped in instruction space.
This note is correct. However, we will add additional note in documentation about "secure-padding" (64K) of unsigned image. Thanks for sharing feedback here!So, this "padded to the next 4096 byte boundary" statement in the doc is wrong?
(One recommendation) This space can still be utilised for some of the other partitions, e.g., NVS which do not have 64K alignment requirement.But application partitions must be aligned on 64KB address, therefore 60KB after the signature is wasted.
Hope this helps!
Mahavir
https://github.com/mahavirj/
https://github.com/mahavirj/
Who is online
Users browsing this forum: Baidu [Spider] and 421 guests