calculate image hash including padding between header and code #4521
Conversation
…code [no changelog]
|
|
why doesn't the same change apply to bootloader image? |
|
it does apply to bootloader, in trezorlib bootloader uses FirmwareImage struct too, and on embedded side bootloader linker script is modified, along with image content check |
There was a problem hiding this comment.
looked briefly at the C code and it seems ok but I'll leave the main review to @cepetr
note: any reason to keep the padding-is-zero check? it seems that we don't have to now (contents are signed) and it may bite us later (e.g., if we want to fill empty spaces with random data, we may not be able to)
|
About the zero check - i just wanted to leave the more strict check, to be entirely clear what should be in that space. But randomizing the data would also make some sense, so for consideration, here it is removed: f34d267 |
| return 0; | ||
| } | ||
| } | ||
| const uint32_t code_start_offset = headers_end_offset; |
There was a problem hiding this comment.
headers_end_offset and headers_end_offset are same. I think we don't need them both.
…en header and code
This PR alters the way image hashes are calculated.
Padding between headers and code is now included into hashed area.
In practice, this affects only U5G models, as image and vendor headers are aligned to 512B and such is also is the code alignment on F4 and U585.
T3W1, even though running on U5G, both its image headers and vendor headers are aligned to 1024B, by coincidence, so existing boardloaders and bootloaders should continue to work.
Therefore, only D002 will break and needs reflashing of board+bootloader to work.
Thanks to this change, code alignment can be omitted from trezorctl.