Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Checksum documentation #44

Open
dzarda opened this issue Nov 29, 2021 · 4 comments
Open

Checksum documentation #44

dzarda opened this issue Nov 29, 2021 · 4 comments

Comments

@dzarda
Copy link
Contributor

dzarda commented Nov 29, 2021

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_START up 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?

@dmitrystu
Copy link
Owner

dmitrystu commented Nov 29, 2021

  • 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.

@dzarda
Copy link
Contributor Author

dzarda commented Dec 6, 2021

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.

@dzarda
Copy link
Contributor Author

dzarda commented Dec 6, 2021

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.

@dmitrystu
Copy link
Owner

Found an interesting article. So I think that 32-bit checksums are good for the small devices, but I prefer a 64-bit if it doesn't consume an extra flash page.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants