|
|
|
Re: [PATCH 1/3] sha512: make it work, undo percpu message schedule | |
| [Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] | |
On Sat, Jan 14, 2012 at 09:27:37PM +0300, Alexey Dobriyan wrote: > 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@xxxxxxxxx> > Cc: stable@xxxxxxxxxxxxxxx OK, I've applied patches 1-2 to crypto and patch 3 to cryptodev. Thanks, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html