diff options
author | Ard Biesheuvel <ard.biesheuvel@linaro.org> | 2018-09-26 12:51:59 +0300 |
---|---|---|
committer | Herbert Xu <herbert@gondor.apana.org.au> | 2018-10-05 05:22:47 +0300 |
commit | cfa1d74495aa3cf240fd2b1fb45d43cc2a754a46 (patch) | |
tree | d136a6dc81c47510d4c8efc742378e8d6aedf35b /drivers/crypto/caam | |
parent | 5182f26f6f7437213adac8290ac746336c7709da (diff) | |
download | linux-cfa1d74495aa3cf240fd2b1fb45d43cc2a754a46.tar.xz |
crypto: qat - move temp buffers off the stack
Arnd reports that with Kees's latest VLA patches applied, the HMAC
handling in the QAT driver uses a worst case estimate of 160 bytes
for the SHA blocksize, allowing the compiler to determine the size
of the stack frame at compile time and throw a warning:
drivers/crypto/qat/qat_common/qat_algs.c: In function 'qat_alg_do_precomputes':
drivers/crypto/qat/qat_common/qat_algs.c:257:1: error: the frame size
of 1112 bytes is larger than 1024 bytes [-Werror=frame-larger-than=]
Given that this worst case estimate is only 32 bytes larger than the
actual block size of SHA-512, the use of a VLA here was hiding the
excessive size of the stack frame from the compiler, and so we should
try to move these buffers off the stack.
So move the ipad/opad buffers and the various SHA state descriptors
into the tfm context struct. Since qat_alg_do_precomputes() is only
called in the context of a setkey() operation, this should be safe.
Using SHA512_BLOCK_SIZE for the size of the ipad/opad buffers allows
them to be used by SHA-1/SHA-256 as well.
Reported-by: Arnd Bergmann <arnd@arndb.de>
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Kees Cook <keescook@chromium.org>
Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'drivers/crypto/caam')
0 files changed, 0 insertions, 0 deletions