On Sun, May 31, 2009 at 09:46:23PM -0700, David Miller wrote:
>
> I don't even want to think about what this does to IPSEC rule creation
> rates, that that matters heavily for cell phone networks where
> hundreds of thousands of nodes come in and out of the server and each
> such entry requires cr
From: Rik van Riel
Date: Sun, 31 May 2009 10:38:52 -0400
> David Miller wrote:
>> From: "Larry H."
>> Date: Sat, 30 May 2009 19:57:20 -0700
>>
>>> [PATCH] Use kzfree in crypto API context initialization and key/iv
>>> handling
>> Thanks for not CC:ing the crypto list, and also not CC:'ing the
>
matthieu castet wrote:
> airo driver hang with 2.6.24-6 on a PIII.
> It seems it it because it need aes crypto.
> It will first try to load padlock-aes, but it fails to load
> Then it load geode_aes which load, and airo hang (airo seems to use
> geode_aes). [1]
[...]
geode_aes is a PCI driver and
David Miller wrote:
From: "Larry H."
Date: Sat, 30 May 2009 19:57:20 -0700
[PATCH] Use kzfree in crypto API context initialization and key/iv handling
Thanks for not CC:ing the crypto list, and also not CC:'ing the
crypto maintainer.
Your submissions leave a lot to be desired, on every leve
On Sun, May 31, 2009 at 03:01:19PM +0200, Martin Willi wrote:
>
> Yes, it fixes HMAC calculation with enabled SLAB debugging.
Thanks for confirming. I'll push the fix through.
--
Visit Openswan at http://www.openswan.org/
Email: Herbert Xu ~{PmV>HI~}
Home Page: http://gondor.apana.org.au/~herbe
Hi Linus:
This push fixes a regression that triggers with SLAB debugging on,
where the new ahash code fails to handle sg entries that cross page
boundaries which are generated by kmalloc.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
master.kernel.or
> You must getting an sg entry that crosses a page boundary, rather than
> two sg entries that both stay within a page.
Yes.
> These things are very rare, and usually occurs as
> a result of SLAB debugging causing kmalloc to return memory that
> crosses page boundaries.
Indeed, SLAB_DEBUG was en
On 30 May 2009 at 20:05, Ingo Molnar wrote:
> I think there's a rather significant omission here: there's no
> discussion about on-kernel-stack information leaking out.
>
> If a thread that does a crypto call happens to leave sensitive
> on-stack data (this can happen easily as stack variables
> > Also, there's no discussion about long-lived threads keeping
> > sensitive information in there kernel stack indefinitely.
>
> kernel stack clearing isn't hard to do, just do it on every syscall exit
> and in the infinite loop for kernel threads.
Actually that is probably not as important. I
