summaryrefslogtreecommitdiff
path: root/block
diff options
context:
space:
mode:
authorAlexey Dobriyan <adobriyan@gmail.com>2012-01-14 21:27:37 +0300
committerHerbert Xu <herbert@gondor.apana.org.au>2012-01-15 12:39:17 +1100
commit84e31fdb7c797a7303e0cc295cb9bc8b73fb872d (patch)
tree2faa3f9c8a36ad97da8de1f269b979158d51f11b /block
parent08c70fc3a239475122e20b7a21dfae4c264c24f7 (diff)
crypto: sha512 - make it work, undo percpu message schedule
commit f9e2bca6c22d75a289a349f869701214d63b5060 aka "crypto: sha512 - Move message schedule W[80] to static percpu area" created global message schedule area. If sha512_update will ever be entered twice, hash will be silently calculated incorrectly. Probably the easiest way to notice incorrect hashes being calculated is to run 2 ping floods over AH with hmac(sha512): #!/usr/sbin/setkey -f flush; spdflush; add IP1 IP2 ah 25 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000025; add IP2 IP1 ah 52 -A hmac-sha512 0x00000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000052; spdadd IP1 IP2 any -P out ipsec ah/transport//require; spdadd IP2 IP1 any -P in ipsec ah/transport//require; XfrmInStateProtoError will start ticking with -EBADMSG being returned from ah_input(). This never happens with, say, hmac(sha1). With patch applied (on BOTH sides), XfrmInStateProtoError does not tick with multiple bidirectional ping flood streams like it doesn't tick with SHA-1. After this patch sha512_transform() will start using ~750 bytes of stack on x86_64. This is OK for simple loads, for something more heavy, stack reduction will be done separatedly. Signed-off-by: Alexey Dobriyan <adobriyan@gmail.com> Cc: stable@vger.kernel.org Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>
Diffstat (limited to 'block')
0 files changed, 0 insertions, 0 deletions