Implement the Swap Hash algorithm

[d3zd3z]

Pushing this early to get some review on the docs.

[Laczen]

@d3zd3z, Hi this is a nice proposal but maybe there is a way to better support devices with large write block sizes.

Suppose that instead of updating the progress status, the progress status is precalculated. E.g. a (running) crc32 would be calculated for each sector and this is written to the status before starting the upgrade. This can be written once taking into account the write block size. The progress is then determined by comparing the crc32 with the one that has been precalculated, as soon as a crc32 differs from the expected we have found the place where the upgrade has stopped, the upgrade can be restarted from this point.

@danieldegrasse, for your info.

[d3zd3z]

@Laczen thanks for the suggestion. I'm not sure I see how this differs very much from what I'm proposing, though. A running sum, vs just having a hash of each block still needs to store that value. And, we still need to pre-compute them to make sure there aren't any collisions (and perhaps change a seed value).

[Laczen]

After going through the documentation once more I think it is basically the same. IMO this should be the standard method as it allows removing the swap status from the image slots.

[nvlsianpu]

@d3zd3z As I went through this RFC I found it as outstanding mechanism. It was not clear to me was when HASH'es are written (as I understand now that happens only twice either before the sliding and the swap operations). Maybe worth to introduce a wording and decryption for highlight that all HASH'es are written at once, and that HASH'es list is a control matrix for slots.

[d3zd3z]

@nvlsianpu writes:

It was not clear to me was when HASH'es are written

They are computed and written once, before any flash operations are started. There is no update to them between slide and swap, as the same hashes apply.

I probably have to think a bit about hashes and encryption, though, as using encryption might require some trickery to avoid having to have twice as many hashes.

[github-actions[bot]]

This pull request has been marked as stale because it has been open (more than) 60 days with no activity. Remove the stale label or add a comment saying that you would like to have the label removed otherwise this pull request will automatically be closed in 14 days. Note, that you can always re-open a closed pull request at any time.