From: Alexey Dobriyan <adobriyan@gmail•com>
To: herbert@gondor•apana.org.au
Cc: linux-crypto@vger•kernel.org, netdev@vger•kernel.org, ken@codelabs•ch
Subject: sha512: make it work, undo percpu message schedule
Date: Wed, 11 Jan 2012 03:00:40 +0300 [thread overview]
Message-ID: <20120111000040.GA3801@p183.telecom.by> (raw)
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, hilarity ensures.
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).
I personally don't understand this changelog entry:
"The message schedule W (u64[80]) is too big for the stack."
Hash context is dynamically allocated.
W[80] stack usage can be trimmed like in SHA-1, this is for separate patch.
P. S.: If only one ping flood runs, XfrmInStateProtoError will also tick
but very slowly. I personally can't explain this.
With patch applied (on BOTH sides), XfrmInStateProtoError does not tick
with multiple bidirectional ping flood streams like it doesn't tick
with SHA-1.
Signed-off-by: Alexey Dobriyan <adobriyan@gmail•com>
---
crypto/sha512_generic.c | 6 +-----
1 file changed, 1 insertion(+), 5 deletions(-)
--- a/crypto/sha512_generic.c
+++ b/crypto/sha512_generic.c
@@ -21,8 +21,6 @@
#include <linux/percpu.h>
#include <asm/byteorder.h>
-static DEFINE_PER_CPU(u64[80], msg_schedule);
-
static inline u64 Ch(u64 x, u64 y, u64 z)
{
return z ^ (x & (y ^ z));
@@ -89,7 +87,7 @@ sha512_transform(u64 *state, const u8 *input)
u64 a, b, c, d, e, f, g, h, t1, t2;
int i;
- u64 *W = get_cpu_var(msg_schedule);
+ u64 W[80];
/* load the input */
for (i = 0; i < 16; i++)
@@ -128,8 +126,6 @@ sha512_transform(u64 *state, const u8 *input)
/* erase our data */
a = b = c = d = e = f = g = h = t1 = t2 = 0;
- memset(W, 0, sizeof(__get_cpu_var(msg_schedule)));
- put_cpu_var(msg_schedule);
}
static int
next reply other threads:[~2012-01-11 0:00 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-11 0:00 Alexey Dobriyan [this message]
2012-01-11 0:12 ` sha512: make it work, undo percpu message schedule Alexey Dobriyan
2012-01-11 0:36 ` Herbert Xu
2012-01-12 23:55 ` Alexey Dobriyan
2012-01-13 0:19 ` Herbert Xu
2012-01-13 7:08 ` Herbert Xu
2012-01-13 10:35 ` Eric Dumazet
2012-01-13 10:41 ` Eric Dumazet
2012-01-13 10:57 ` Eric Dumazet
2012-01-13 11:33 ` Alexey Dobriyan
2012-01-13 12:34 ` Eric Dumazet
2012-01-14 18:20 ` Alexey Dobriyan
2012-01-14 18:27 ` [PATCH 1/3] " Alexey Dobriyan
2012-01-14 18:40 ` [PATCH 2/3] sha512: reduce stack usage to safe number Alexey Dobriyan
2012-01-14 19:08 ` Linus Torvalds
2012-01-14 20:41 ` Alexey Dobriyan
2012-01-14 21:14 ` Linus Torvalds
2012-01-16 9:56 ` David Laight
2012-01-16 10:20 ` Alexey Dobriyan
2012-01-16 10:23 ` Eric Dumazet
2012-01-16 11:37 ` David Laight
2012-01-17 12:03 ` Alexey Dobriyan
2012-01-18 18:02 ` [PATCH 4/3] sha512: reduce stack usage even on i386 Alexey Dobriyan
2012-01-26 2:35 ` Herbert Xu
2012-01-27 17:51 ` Alexey Dobriyan
2012-01-27 22:32 ` Herbert Xu
2012-01-30 11:10 ` Alexey Dobriyan
2012-02-03 3:34 ` Herbert Xu
2012-01-14 21:46 ` [PATCH 1/3] sha512: make it work, undo percpu message schedule Eric Dumazet
2012-01-14 21:52 ` Linus Torvalds
2012-01-14 22:00 ` Eric Dumazet
2012-01-15 1:43 ` Herbert Xu
2012-01-13 11:02 ` Steffen Klassert
2012-01-15 1:43 ` Herbert Xu
2012-01-13 11:45 ` David Laight
2012-01-13 12:35 ` Eric Dumazet
2012-01-13 6:22 ` Steffen Klassert
2012-01-13 6:46 ` Herbert Xu
2012-01-13 6:48 ` Eric Dumazet
2012-01-13 6:50 ` Herbert Xu
2012-01-13 9:45 ` David Laight
2012-01-11 1:12 ` Adrian-Ken Rueegsegger
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20120111000040.GA3801@p183.telecom.by \
--to=adobriyan@gmail$(echo .)com \
--cc=herbert@gondor$(echo .)apana.org.au \
--cc=ken@codelabs$(echo .)ch \
--cc=linux-crypto@vger$(echo .)kernel.org \
--cc=netdev@vger$(echo .)kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox