summaryrefslogtreecommitdiff
path: root/Makefile
diff options
context:
space:
mode:
authorJulius Werner <jwerner@chromium.org>2020-05-05 20:31:33 -0700
committerCommit Bot <commit-bot@chromium.org>2020-05-12 04:08:06 +0000
commitd6c392bb12b6d52d880b72b24d68e59ad8e8d609 (patch)
treedfe016b0c68b900aee48c2cc482114086b1360e6 /Makefile
parent909d55215f7573d67e38931bb31ac12694312a7d (diff)
downloadvboot-d6c392bb12b6d52d880b72b24d68e59ad8e8d609.tar.gz
2sha: Add SHA-224 and SHA-384 hash algorithms
This patch adds support for the SHA-224 and SHA-384 hash algorithms, which are basically just variants of SHA-256 and SHA-512 (respectively) with different initialization vectors and truncating a bit of the final output. They are only added to serve vboot's role as all-purpose crypto toolbox for callers (e.g. coreboot, where I need SHA-384 to support a certain SoC boot descriptor right now) and not intended for actual use as signature or firmware body hashes -- therefore, we only add the hash algorithms themselves and don't create enum values for them in enum vb2_crypto_algorithm or other structures. Also clarify the difference between UNROLL_LOOPS and UNROLL_LOOPS_SHA512 in the Makefile, since it was totally not obvious to me. BRANCH=None BUG=None TEST=make runtest and make runtest UNROLL_LOOPS=1 Cq-Depend: chromium:2191082 Signed-off-by: Julius Werner <jwerner@chromium.org> Change-Id: Ic132d4dfe5967f03be4666b26c47d32c1235f4a9 Reviewed-on: https://chromium-review.googlesource.com/c/chromiumos/platform/vboot_reference/+/2183551 Reviewed-by: Joel Kitching <kitching@chromium.org>
Diffstat (limited to 'Makefile')
-rw-r--r--Makefile11
1 files changed, 9 insertions, 2 deletions
diff --git a/Makefile b/Makefile
index b5b68b20..10c5c4bf 100644
--- a/Makefile
+++ b/Makefile
@@ -840,11 +840,18 @@ ${TLCL_OBJS}: CFLAGS += -DTPM_BLOCKING_CONTINUESELFTEST
# CFLAGS += -DTPM_MANUAL_SELFTEST
+# NOTE: UNROLL_LOOPS *only* affects SHA256, *not* SHA512. This seems to have
+# been a conscious decision at some point (see b/35501356) but whether it still
+# holds up in all situations on all architectures today might need to be
+# reevaluated. For now, since we currently always use SHA256 for (non-recovery)
+# kernel bodies and don't unroll loops for firmware verification, it's not very
+# relevant in practice. To unroll SHA512, UNROLL_LOOPS_SHA512 would need to be
+# defined.
ifneq ($(filter-out 0,$(UNROLL_LOOPS)),)
-$(info vboot hash algos built with unrolled loops (faster, larger code size))
+$(info vboot SHA256 built with unrolled loops (faster, larger code size))
CFLAGS += -DUNROLL_LOOPS
else
-$(info vboot hash algos built with tight loops (slower, smaller code size))
+$(info vboot SHA256 built with tight loops (slower, smaller code size))
endif
.PHONY: fwlib