crypto: caam - fix non-block aligned hash calculation
authorRussell King <rmk+kernel@arm.linux.org.uk>
Sun, 18 Oct 2015 16:51:20 +0000 (17:51 +0100)
committerHerbert Xu <herbert@gondor.apana.org.au>
Tue, 20 Oct 2015 14:11:10 +0000 (22:11 +0800)
commitc7556ff7e3e4f2747583bcc787f12ec9460ec3a6
treed4b375cb6892fa1bbbbad5e9d4abd9ce8c69a27c
parent434b421241f2d0faa7fea75f6320de00c5e3430e
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: ed03d918b0861c08 3daa0080 f1400000 3d03d938
jobdesc@889: ed03d92800000068 f8400000 3cde2a40 00000028

where the word at 0xed03d928 is the expected data size (0x68), and a
scatterlist containing:

sg@892: ed03d93800000000 3cde2a40 00000028 00000000
sg@892: ed03d94800000000 3d03d100 00000006 00000000
sg@892: ed03d95800000000 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: ed03d93800000000 3cde2a40 00000028 00000000
sg@892: ed03d94800000000 3d03d100 00000026 00000000
sg@892: ed03d95800000000 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>
drivers/crypto/caam/caamhash.c