sboot_stm32
sboot_stm32 copied to clipboard
dmitrystu
Checksum documentation
It's not entirely obvious how the firmware checksum validation works. I seem to have some idea but would like confirmation.
- Encrypter appends checksum and verifies that remainder reaches zero only at the end of image
- Bootloader verifies the whole flash region (
_APP_STARTup until__romend)
Does this mean that the application image should be linked with the resultant size of __romend - _APP_START - 4 in order to guarantee correct checksum verification?
- No. This will work for CRC, but not for FNV1A
- Not quite. Bootloader verifies flash memory until a checksum collision was found or
__romend - sizeof(checksum)was reached.
Therefore, not necessary to get the resultant size of the full free ROM. The еncryptor checks firmware for the collisions after appending checksum and guarantee the only correct collision exist. Of course, there is a small probability to get a bad collision in the junked free space or in the broken firmware, but this is applicable to any type of hash or CRC. BTW. I have tested and compared CRC32 vs FNV1A32 on the random data and found that FNV is much better for this use case.
Okay. I'm trying to figure out the probability of collision in the free space... Logic tells me that in case of 65k of free space, this amount would simply be subtracted from the 4 billion possible codes, only introducing a very slight probability, as you say.
Also when considering the remainder of flash memory - that's not really random data, is it. Perhaps would be better modeled as FFFF.
Actually, after further thought, the probability is quite a bit more substantial IMHO. Introducing 65000 more OK-codes does not simply subtract, but rather divide the checksum codespace by that amount.
That's moving from 1 in 4B towards 65k in 4B. Therefore the resultant checksum would only have a strenght of 16 bits instead of 32. Again, that's when considering random distribution.