On Wed, 15 Sept 2021 at 13:33, Alexandru Gagniuc <mr.nuke...@gmail.com> wrote:
>
> Target code and mkimage share the same hashing infrastructure. If one
> is wrong, it's very likely that both are wrong in the same way. Thus
> testing won't catch hash regressions. This already happened in
> commit 92055e138f28 ("image: Drop if/elseif hash selection in
> calculate_hash()"). None of the tests caught that CRC32 was broken.
>
> Instead of testing hash_calculate() against itself, create a FIT with
> containing a kernel with pre-calculated hashes. Then check the hashes
> produced against the known good hashes.
>
> Signed-off-by: Alexandru Gagniuc <mr.nuke...@gmail.com>
>
> ---
> Desired:
> $ ./test/py/test.py -k hash
> ...
> test_mkimage_hashes PASSED
>
> Is very cryptic with regards to what is going on. It would be much
> nicer to have tests named "crc32", "sha256", and so on. But I don't
> know how to do that without several pyton functions each assembling
> their own damn FIT.
> I think it would also be nicer for the test log to show
> test_sha1 PASSED
> test_crc32 PASSED
> test_md5 FAILED
>
> test/py/tests/test_fit_hashes.py | 111 ++++++++++++++++++++++++++++
> test/py/tests/vboot/hash-images.its | 76 +++++++++++++++++++
> 2 files changed, 187 insertions(+)
> create mode 100644 test/py/tests/test_fit_hashes.py
> create mode 100644 test/py/tests/vboot/hash-images.its
>
Reviewed-by: Simon Glass <s...@chromium.org>
