CR50: have the TPM2 library always use software SHA

As discussed in the associated bug, interleaving usage
of the key-ladder and the h/w SHA engine is not supported
by the underlying hardware.  So far this limitation has
not been an issue since the key-ladder was not used during
run-time, however this is changing with encrypted NVMEM
support.

Once we can guarantee that the key-ladder will not be
invoked between SHA_init() and final(), we can re-enable
h/w support for TPM2 code.

The performance impact to TPM2 operations is expected to
be minor, since the data being hashed is at most a few kB.

BRANCH=none
BUG=chrome-os-partner:55331
TEST=TCG tests pass

Change-Id: Ia0a565af7179d0b3745eb465220ba844feaecb92
Signed-off-by: nagendra modadugu <ngm@google.com>
Reviewed-on: https://chromium-review.googlesource.com/430292
Commit-Ready: Marius Schilder <mschilder@chromium.org>
Tested-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Marius Schilder <mschilder@chromium.org>
Reviewed-by: Vadim Bendebury <vbendeb@chromium.org>
This commit is contained in:
nagendra modadugu
2017-01-18 14:38:01 -08:00
committed by chrome-bot
parent 423eac3ac1
commit 2ad394d5c0

View File

@@ -95,13 +95,19 @@ uint16_t _cpri__StartHash(TPM_ALG_ID alg, BOOL sequence,
struct HASH_CTX *ctx = (struct HASH_CTX *) state->state;
uint16_t result;
/* NOTE: as per bug http://crosbug.com/p/55331#26 (NVMEM
* encryption), always use the software hash implementation
* for TPM related calculations, since we have no guarantee
* that the key-ladder will not be used between SHA_init() and
* final().
*/
switch (alg) {
case TPM_ALG_SHA1:
DCRYPTO_SHA1_init(ctx, sequence);
DCRYPTO_SHA1_init(ctx, 1);
result = HASH_size(ctx);
break;
case TPM_ALG_SHA256:
DCRYPTO_SHA256_init(ctx, sequence);
DCRYPTO_SHA256_init(ctx, 1);
result = HASH_size(ctx);
break;