misc stuff).
Not compile tested on csky, hexagon, nds32, openrisc.
Love,
Alexey
Signed-off-by: Alexey Dobriyan
#!/bin/sh -x
find . -type f -name '*.h' -print |\
LC_ALL=C sort |\
sed -e 's#^./##g' |\
xargs ./script
On Sun, Jun 24, 2018 at 09:11:05AM +0200, Ingo Molnar wrote:
> > Add explicit RETs to the tail calls of AEGIS and MORUS crypto algorithms
> > otherwise they run into INT3 padding due to
> >
> > 51bad67ffbce ("x86/asm: Pad assembly functions with INT3 instructions")
> >
> > leading to spurious d
On Wed, Feb 15, 2012 at 12:23:52AM -0500, David Miller wrote:
> From: Herbert Xu
> 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 go back to the per
On 1/28/12, Herbert Xu 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 conta
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
4225 712 049371349 ../sha512_generic-i386-001.o
Signed-off-by: Alexey Dobriyan
Cc: sta...@vger.kernel.org
---
crypto/sha512_generic.c | 42 --
1 file changed, 20 insertions(+), 22 deletions(-)
--- a/crypto/sha512_generic.c
+++ b/c
On 1/16/12, Eric Dumazet 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 < 16; i +=
On 1/16/12, David Laight 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, f, g, h, a)
On Sat, Jan 14, 2012 at 11:08:45AM -0800, Linus Torvalds wrote:
> On Sat, Jan 14, 2012 at 10:40 AM, Alexey Dobriyan wrote:
> >
> > Line by line explanation:
> > * BLEND_OP
> > array is "circular" now, all indexes have to be modulo 16.
> > Round number
tree crypto test 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
Cc: sta...@vger.kernel.org
---
This is patch is for stable if 750 byt
his should make the code
faster.
Patch survives in-tree crypto test and ping flood with hmac(sha512) on.
Signed-off-by: Alexey Dobriyan
---
crypto/sha512_generic.c | 13 -
include/linux/bitops.h | 20
2 files changed, 24 insertions(+), 9 deletions(-
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
Cc: sta...@vger.kernel.org
---
crypto/sha512_generic.c |6 +-
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 wrote:
> >
> > > + static u64 msg_schedule[80];
> > > + static DEFINE_SPINLOCK(msg_schedule_lock);
&
On 1/13/12, Eric Dumazet 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 selfcryptotest passed, so you wo
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"
> > creat
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
tiple bidirectional ping flood streams like it doesn't tick
with SHA-1.
Signed-off-by: Alexey Dobriyan
---
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
#inclu
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 f
On Tue, Nov 8, 2011 at 8:24 AM, Peter P Waskiewicz Jr
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 that their daemon
>> sup
rc[0] is unused because rounds are counted from 1.
Save an u64!
Signed-off-by: Alexey Dobriyan
---
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[256
On Mon, Mar 1, 2010 at 11:32 AM, Mikael Pettersson wrote:
> Arjan van de Ven writes:
> > On Sat, 27 Feb 2010 21:47:42 +0100
> > Roel Kluin wrote:
> > > +void secure_bzero(void *p, size_t n)
> > > +{
> > > + memset(p, 0, n);
> > > + ARRAY_PREVENT_DSE(p, n);
> > > +}
> > > +EXPORT_SYMBOL(
On Wed, Feb 17, 2010 at 08:37:35AM +0800, Herbert Xu wrote:
> On Tue, Feb 16, 2010 at 09:31:39PM +0200, Alexey Dobriyan wrote:
> >
> > Which codepath exactly?
>
> When a spawn is created the instance associated with it will have
> a zero-initialised cra_users entry.
>
On Tue, Feb 16, 2010 at 08:02:03PM +0800, Herbert Xu wrote:
> On Mon, Feb 15, 2010 at 10:14:08AM +0200, Alexey Dobriyan wrote:
> >
> > Yes, ipcomp bug triggers almost immediately.
> > Anyway, this is just description of what I do.
>
> Can you see if this patch make
On Mon, Feb 15, 2010 at 10:11 AM, Herbert Xu
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
>> wrote:
>> > Is this reproducible every time you unload aes_x86_64 after boot?
>>
>> No, w
On Mon, Feb 15, 2010 at 7:27 AM, Herbert Xu 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 workload and it hits sometimes wi
BUG: unable to handle kernel NULL pointer dereference at 0018
IP: [] crypto_remove_spawns+0xd4/0x340
PGD bdc48067 PUD bc954067 PMD 0
Oops: [#1] PREEMPT SMP DEBUG_PAGEALLOC
last sysfs file:
/sys/devices/pci:00/:00:1f.2/host0/target0:0:0/0:0:0:0/block/sda/uevent
CPU 0
Pid:
On Fri, Feb 06, 2009 at 03:54:38PM +0100, Frank Seidel wrote:
> Alexey Dobriyan schrieb:
> > On Fri, Feb 06, 2009 at 03:19:10PM +0100, Frank Seidel wrote:
> >> According to kerneljanitors todo list all printk calls (beginning
> >> a new line) should have a
On Fri, Feb 06, 2009 at 03:19:10PM +0100, Frank Seidel wrote:
> According to kerneljanitors todo list all printk calls (beginning
> a new line) should have an according KERN_* constant.
Forget about kernel janitors todo list, fix a bug instead.
> Those are the missing pieces here for the crypto s
28 matches
Mail list logo
