secure boot: Pad to avoid data after the signature mapping into the address space

Because address space is mapped in 64KB pages, it was possible for unauthenticated data after the
app .bin to become mapped into the flash cache address space.

This problem is solved by 2 changes:

* "esptool elf2image --secure-pad" will pad the image so that the signature block ends close to the
  64KB boundary. Due to alignment constraints it will be 12 bytes too short after signing (but
  with flash encryption, these 12 bytes are still encrypted as part of the last block and can't be
  arbitrarily changed).
* By default, secure boot now requires all app partitions to be a multiple of 64KB in size.
This commit is contained in:
Angus Gratton
2018-07-13 11:52:57 +10:00
committed by Angus Gratton
parent 7f382f461c
commit 57b601ab7f
6 changed files with 34 additions and 4 deletions

View File

@@ -275,6 +275,13 @@ config SECURE_BOOT_ALLOW_JTAG
Only set this option in testing environments.
config SECURE_BOOT_ALLOW_SHORT_APP_PARTITION
bool "Allow app partition length not 64KB aligned"
depends on SECURE_BOOT_INSECURE
help
If not set (default), app partition size must be a multiple of 64KB. App images are padded to 64KB length, and the bootloader checks any trailing bytes after the signature (before the next 64KB boundary) have not been written. This is because flash cache maps entire 64KB pages into the address space. This prevents an attacker from appending unverified data after the app image in the flash, causing it to be mapped into the address space.
Setting this option allows the app partition length to be unaligned, and disables padding of the app image to this length. It is generally not recommended to set this option, unless you have a legacy partitioning scheme which doesn't support 64KB aligned partition lengths.
config FLASH_ENCRYPTION_UART_BOOTLOADER_ALLOW_ENCRYPT
bool "Leave UART bootloader encryption enabled"