summaryrefslogtreecommitdiff
path: root/drivers/crypto
diff options
context:
space:
mode:
authorRussell King <rmk+kernel@arm.linux.org.uk>2015-10-18 17:51:20 +0100
committerHerbert Xu <herbert@gondor.apana.org.au>2015-10-20 22:11:10 +0800
commitc7556ff7e3e4f2747583bcc787f12ec9460ec3a6 (patch)
treed4b375cb6892fa1bbbbad5e9d4abd9ce8c69a27c /drivers/crypto
parent434b421241f2d0faa7fea75f6320de00c5e3430e (diff)
downloadlinux-next-c7556ff7e3e4f2747583bcc787f12ec9460ec3a6.tar.gz
crypto: caam - fix non-block aligned hash calculation
caam does not properly calculate the size of the retained state when non-block aligned hashes are requested - it uses the wrong buffer sizes, which results in errors such as: caam_jr 2102000.jr1: 40000501: DECO: desc idx 5: SGT Length Error. The descriptor is trying to read more data than is contained in the SGT table. We end up here with: in_len 0x46 blocksize 0x40 last_bufsize 0x0 next_bufsize 0x6 to_hash 0x40 ctx_len 0x28 nbytes 0x20 which results in a job descriptor of: jobdesc@889: ed03d918: b0861c08 3daa0080 f1400000 3d03d938 jobdesc@889: ed03d928: 00000068 f8400000 3cde2a40 00000028 where the word at 0xed03d928 is the expected data size (0x68), and a scatterlist containing: sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000 sg@892: ed03d948: 00000000 3d03d100 00000006 00000000 sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000 0x68 comes from 0x28 (the context size) plus the "in_len" rounded down to a block size (0x40). in_len comes from 0x26 bytes of unhashed data from the previous operation, plus the 0x20 bytes from the latest operation. The fixed version would create: sg@892: ed03d938: 00000000 3cde2a40 00000028 00000000 sg@892: ed03d948: 00000000 3d03d100 00000026 00000000 sg@892: ed03d958: 00000000 7e8aa700 40000020 00000000 which replaces the 0x06 length with the correct 0x26 bytes of previously unhashed data. This fixes a previous commit which erroneously "fixed" this due to a DMA-API bug report; that commit indicates that the bug was caused via a test_ahash_pnum() function in the tcrypt module. No such function has ever existed in the mainline kernel. Given that the change in this commit has been tested with DMA API debug enabled and shows no issue, I can only conclude that test_ahash_pnum() was triggering that bad behaviour by CAAM. Fixes: 7d5196aba3c8 ("crypto: caam - Correct DMA unmap size in ahash_update_ctx()") Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'drivers/crypto')
-rw-r--r--drivers/crypto/caam/caamhash.c2
1 files changed, 1 insertions, 1 deletions
diff --git a/drivers/crypto/caam/caamhash.c b/drivers/crypto/caam/caamhash.c
index cb7af558b176..cafc0018dca1 100644
--- a/drivers/crypto/caam/caamhash.c
+++ b/drivers/crypto/caam/caamhash.c
@@ -823,7 +823,7 @@ static int ahash_update_ctx(struct ahash_request *req)
state->buf_dma = try_buf_map_to_sec4_sg(jrdev,
edesc->sec4_sg + 1,
buf, state->buf_dma,
- *next_buflen, *buflen);
+ *buflen, last_buflen);
if (src_nents) {
src_map_to_sec4_sg(jrdev, req->src, src_nents,