On Wed, Feb 15, 2012 at 12:23:52AM -0500, David Miller wrote:
From: Herbert Xu herb...@gondor.hengli.com.au
Date: Wed, 15 Feb 2012 16:16:08 +1100
OK, so we grew by 1136 - 888 = 248. Keep in mind that 128 of
that is expected since we moved W onto the stack.
Right.
I guess we could
On 1/28/12, Herbert Xu herb...@gondor.apana.org.au wrote:
On Fri, Jan 27, 2012 at 08:51:30PM +0300, Alexey Dobriyan wrote:
I think this is because your tree contained %16 code instead if 15.
Now that it contains 15 it should become applicable.
OK
On Thu, Jan 26, 2012 at 01:35:02PM +1100, Herbert Xu wrote:
On Wed, Jan 18, 2012 at 09:02:10PM +0300, Alexey Dobriyan wrote:
Fix still excessive stack usage on i386.
There is too much loop unrolling going on, despite W[16] being used,
gcc screws up this for some reason. So, don't
712 049371349 ../sha512_generic-i386-001.o
Signed-off-by: Alexey Dobriyan adobri...@gmail.com
Cc: sta...@vger.kernel.org
---
crypto/sha512_generic.c | 42 --
1 file changed, 20 insertions(+), 22 deletions(-)
--- a/crypto/sha512_generic.c
On 1/16/12, Eric Dumazet eric.duma...@gmail.com wrote:
Le lundi 16 janvier 2012 à 09:56 +, David Laight a écrit :
Doesn't this badly overflow W[] ..
+#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
+ t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i]; \
...
+ for (i = 0; i
On 1/16/12, David Laight david.lai...@aculab.com wrote:
Doesn't this badly overflow W[] ..
+#define SHA512_0_15(i, a, b, c, d, e, f, g, h) \
+t1 = h + e1(e) + Ch(e, f, g) + sha512_K[i] + W[i]; \
...
+for (i = 0; i 16; i += 8) {
...
+SHA512_0_15(i + 7, b, c, d, e,
On Fri, Jan 13, 2012 at 01:34:13PM +0100, Eric Dumazet wrote:
Le vendredi 13 janvier 2012 à 13:33 +0200, Alexey Dobriyan a écrit :
On 1/13/12, Eric Dumazet eric.duma...@gmail.com wrote:
+ static u64 msg_schedule[80];
+ static DEFINE_SPINLOCK(msg_schedule_lock);
No guys
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 adobri...@gmail.com
Cc: sta...@vger.kernel.org
---
crypto/sha512_generic.c |6
the code
faster.
Patch survives in-tree crypto test and ping flood with hmac(sha512) on.
Signed-off-by: Alexey Dobriyan adobri...@gmail.com
---
crypto/sha512_generic.c | 13 -
include/linux/bitops.h | 20
2 files changed, 24 insertions(+), 9 deletions
and original bugreport test
(ping flood with hmac(sha512).
See FIPS 180-2 for SHA-512 definition
http://csrc.nist.gov/publications/fips/fips180-2/fips180-2withchangenotice.pdf
Signed-off-by: Alexey Dobriyan adobri...@gmail.com
Cc: sta...@vger.kernel.org
---
This is patch is for stable if 750 byte stack
On Sat, Jan 14, 2012 at 11:08:45AM -0800, Linus Torvalds wrote:
On Sat, Jan 14, 2012 at 10:40 AM, Alexey Dobriyan adobri...@gmail.com wrote:
Line by line explanation:
* BLEND_OP
array is circular now, all indexes have to be modulo 16.
Round number is positive, so remainder operation
On 1/13/12, Eric Dumazet eric.duma...@gmail.com wrote:
+ static u64 msg_schedule[80];
+ static DEFINE_SPINLOCK(msg_schedule_lock);
No guys, no.
SHA-512 only needs u64[16] running window for message scheduling.
I'm sending whitespace mangled patch which is only tested
with
On Wed, Jan 11, 2012 at 11:36:11AM +1100, Herbert Xu wrote:
On Wed, Jan 11, 2012 at 03:00:40AM +0300, Alexey Dobriyan wrote:
commit f9e2bca6c22d75a289a349f869701214d63b5060
aka crypto: sha512 - Move message schedule W[80] to static percpu area
created global message schedule area
On Wed, Jan 11, 2012 at 03:00:40AM +0300, Alexey Dobriyan wrote:
- memset(W, 0, sizeof(__get_cpu_var(msg_schedule)));
And, yes, this is intentional -- modern gcc pisses on stone age data clearing.
--
To unsubscribe from this list: send the line unsubscribe linux-crypto in
the body
aalg_list array contains list of approved HMAC algorightms.
Do I understand correctly that to update this list some sort of
official document like RFC has to be present?
For example, it contains hmac(rmd160) entry, but doesn't contain hmac(rmd128)
and other RIPEMD functions (there is even test
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr
peter.p.waskiewicz...@intel.com wrote:
On Mon, 2011-11-07 at 19:10 -0800, Daniil Stolnikov wrote:
Hello!
Found that the stack IPSec in Linux does not support any IP range. Many
people ask this question. The archives say strongswan said
rc[0] is unused because rounds are counted from 1.
Save an u64!
Signed-off-by: Alexey Dobriyan adobri...@gmail.com
---
crypto/wp512.c | 18 --
1 file changed, 12 insertions(+), 6 deletions(-)
--- a/crypto/wp512.c
+++ b/crypto/wp512.c
@@ -762,11 +762,17 @@ static const u64 C7
On Mon, Mar 1, 2010 at 11:32 AM, Mikael Pettersson mi...@it.uu.se wrote:
Arjan van de Ven writes:
On Sat, 27 Feb 2010 21:47:42 +0100
Roel Kluin roel.kl...@gmail.com wrote:
+void secure_bzero(void *p, size_t n)
+{
+ memset(p, 0, n);
+ ARRAY_PREVENT_DSE(p, n);
+}
On Mon, Feb 15, 2010 at 10:11 AM, Herbert Xu
herb...@gondor.apana.org.au wrote:
On Mon, Feb 15, 2010 at 09:47:25AM +0200, Alexey Dobriyan wrote:
On Mon, Feb 15, 2010 at 7:27 AM, Herbert Xu herb...@gondor.apana.org.au
wrote:
Is this reproducible every time you unload aes_x86_64 after boot
BUG: unable to handle kernel NULL pointer dereference at 0018
IP: [81145bf4] crypto_remove_spawns+0xd4/0x340
PGD bdc48067 PUD bc954067 PMD 0
Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file:
On Mon, Feb 15, 2010 at 7:27 AM, Herbert Xu herb...@gondor.apana.org.au wrote:
Is this reproducible every time you unload aes_x86_64 after boot?
No, what I do is
1. setup ipcomp in tunnel mode _in fresh netns_ and immediately exit
2. modprobe/rmmod all modules (not much)
~1 hour of this
21 matches
Mail list logo
