On Fri, Aug 23, 2013 at 12:56:02PM -0600, Stephen Warren wrote:
> From: Stephen Warren <swarren@xxxxxxxxxx>
>
> In real-world use-cases, hashing zero-length data likely never happens.
> However, it is relevant when testing cbootimage with a dummy zero-length
> bootloader binary, e.g.:
>
> touch u-boot.bin
> cbootimage -t30 ../tamonten-ng/tegra30.img.cfg tegra30-tec-ng.img
>
> In this scenario, it's useful to create a consistent hash, so that one
> can compare the resultant images before and after applying patches, to
> check for regressions.
>
> Signed-off-by: Stephen Warren <swarren@xxxxxxxxxx>
> ---
> src/crypto.c | 3 +++
> 1 file changed, 3 insertions(+)
>
> diff --git a/src/crypto.c b/src/crypto.c
> index 88de357..9741785 100644
> --- a/src/crypto.c
> +++ b/src/crypto.c
> @@ -183,6 +183,9 @@ sign_objext(
> if (enable_debug_crypto)
> print_vector("K1", KEY_LENGTH, k1);
>
> + if (!num_aes_blocks)
> + memset(dst, 0, 4 * NVAES_STATECOLS);
> +
Perhaps it would be better to zero out the memory after allocating it in
sign_bct()? Or alternatively use:
hash_buffer = calloc(1, hash_size);
That way you're sure to get the size right and don't have to hardcode
it. The above patch will only work as long as the hash size across SoCs
remains the same.
Thierry
Attachment:
pgpa4M1UEmCDX.pgp
Description: PGP signature
