From: Yashpal Dutta
KMap the buffers before copying trailing bytes during hmac in CAAM driver into a
session temporary buffer. This is required if pinned buffer from user-space
is send to CAAM driver during hmac and is safe even if hmac request is generated
from within kernel.
Signed-off-by: Yas
On Tue, Sep 10, 2013 at 11:01:38AM -0300, Lucas De Marchi wrote:
>
> However looking at the only user right now, crct10dif: couldn't we
> detect at runtime if this module can be used instead of just trying to
> load it as a pre softdep and possibly failing?
No as sd_mod requires crct10dif to be pr
Please don't trim cc lists!
James Yonan wrote:
>
> I tried this patch, but I still see an apparent module lookup/load race
> if code on several CPUs calls crypto_alloc_aead at the same time, and an
> external module such as aes needs to be loaded.
>
> Seeing this in the log: "request_module:
On 09/10/2013 08:38 PM, James Yonan wrote:
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker.
Bytewise memory comparisons (such as memcmp) are us
When comparing MAC hashes, AEAD authentication tags, or other hash
values in the context of authentication or integrity checking, it
is important not to leak timing information to a potential attacker.
Bytewise memory comparisons (such as memcmp) are usually optimized so
that they return a nonzero
On 08/30/2013 04:19 AM, Rajendra Nayak wrote:
> []..
>
>> +
>> +#define pr_fmt(fmt) "%s: " fmt, __func__
>> +
>> +#ifdef DEBUG
>> +#define prn(num) printk(#num "=%d\n", num)
>> +#define prx(num) printk(#num "=%x\n", num)
>> +#else
>> +#define prn(num) do { } while (0)
>> +#define prx(num) do { }
On Tue, Sep 10, 2013 at 4:01 PM, Lucas De Marchi
wrote:
> On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu
> wrote:
>> On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote:
>>> Herbert Xu writes:
>>> > Hi Rusty:
>>> >
>>> > I don't know why this patch never went into the kernel, even
>>> >
On Wed, Jul 24, 2013 at 11:03 PM, Herbert Xu
wrote:
> On Thu, Jul 25, 2013 at 09:32:02AM +0930, Rusty Russell wrote:
>> Herbert Xu writes:
>> > Hi Rusty:
>> >
>> > I don't know why this patch never went into the kernel, even
>> > though the corresponding features have been added to modprobe
>> >
