On Tue, Jan 06, 2015 at 06:30:36PM -0800, Marcel Holtmann wrote:
>
> that is indeed true. All the crypto algorithm need to be moved as well. I
> considered that already since I had debugged the initcall order with a kernel
> without modules.
If there were a real user then I would consider it. I
Hi Herbert,
>> we can easily run them later on. However when the Bluetooth subsystem is
>> built as module, then I would prefer to have the module loading fail in case
>> one of the selftest fails. I can hack around this with a lot of ifdef config
>> magic. If we would have all crypto, cipher e
Hi Linus:
This push fixes a build problem with sha-mb with old toolchains
and an implementation bug in the ctr(aes)/by8 branch of aesni-intel
that's enabled when AVX is available.
Please pull from
git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6.git
or
master.kernel.org:/pub/sc
On Mon, Jan 05, 2015 at 09:51:35AM -0800, Tadeusz Struk wrote:
> On 01/05/2015 02:06 AM, Herbert Xu wrote:
> >
> > It appears that the GCM aesni implementation does not support
> > 192/256-bit keys. This is not allowed as accelerated drivers
> > must support everything supported by the software i
On Tue, Jan 06, 2015 at 08:42:26PM +0100, Giel van Schijndel wrote:
>
> Question: are you sure the compiler won't optimize the call to memset(0)
> way if it's immediately followed by kfree()?
Yes it won't be optimised away. However, you could use kzfree.
> Another actually does change a stack-a
On Mon, Jan 05, 2015 at 10:36:37 +1100, Herbert Xu wrote:
> On Sun, Jan 04, 2015 at 11:49:09PM +0100, Giel van Schijndel wrote:
>>
>>> sctx does not point to stack memory so this is bogus.
>>>
>>> Only stack memory cleared just before it goes out of scope needs
>>> memzero_explicit.
>>
>> Is that
