diff options
| author | Stephen Warren <swarren@nvidia.com> | 2013-08-23 11:59:12 -0600 |
|---|---|---|
| committer | Stephen Warren <swarren@nvidia.com> | 2013-08-27 10:04:16 -0600 |
| commit | ce1847a2b3ffc7026db58d800a103e7fdbf9f1ac (patch) | |
| tree | 00e32a617777d21571e71369e4b188d7e027dd51 | |
| parent | 902a58b463f6a59ab48ac0858610cec3ad74685f (diff) | |
| download | nvidia-cbootimage-ce1847a2b3ffc7026db58d800a103e7fdbf9f1ac.tar.gz | |
crypto: produce consistent hash for zero-length data
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.
Hence, zero out the hash data so it has consistent content if it isn't
written to.
Signed-off-by: Stephen Warren <swarren@nvidia.com>
Reviewed-by: Thierry Reding <treding@nvidia.com>
| -rw-r--r-- | src/crypto.c | 2 | ||||
| -rw-r--r-- | src/data_layout.c | 2 |
2 files changed, 2 insertions, 2 deletions
diff --git a/src/crypto.c b/src/crypto.c index 88de357..99e9f08 100644 --- a/src/crypto.c +++ b/src/crypto.c @@ -280,7 +280,7 @@ sign_bct(build_image_context *context, bct) != 0) return -ENODATA; - hash_buffer = malloc(hash_size); + hash_buffer = calloc(1, hash_size); if (hash_buffer == NULL) return -ENOMEM; e = sign_data_block(bct + Offset, length, hash_buffer); diff --git a/src/data_layout.c b/src/data_layout.c index ae62126..cae4c37 100644 --- a/src/data_layout.c +++ b/src/data_layout.c @@ -391,7 +391,7 @@ write_bootloaders(build_image_context *context) g_soc_config->get_value(token_bootloaders_max, &bootloaders_max, context->bct); - hash_buffer = malloc(hash_size); + hash_buffer = calloc(1, hash_size); if (hash_buffer == NULL) return -ENOMEM; |