Kernel crypto framework, sleeping-in-atomic issues

Kernel crypto framework, sleeping-in-atomic issues

[Fabrizio Demaria]

Hello,

I am investigating the current usage of kernel crypto-libraries in the
SCTP code, considering to adopt the same crypto framework for the
MPTCP implementation.

In sm_make_chunk.c, the crypto function "crypto_hash_setkey" is called
in an atomic context, despite the fact that this function CAN invoke a
GFP_KERNEL (sleeping) memory allocation. Calling a sleeping function
from an atomic context can end up in deadlock. Has this factor been
considered when adding the crypto functions into the SCTP code or has
it been safely handled/verified in any way?


Thanks,
Fabrizio

Re: Kernel crypto framework, sleeping-in-atomic issues

[Vlad Yasevich]

On 12/10/2015 10:49 AM, Fabrizio Demaria wrote:
> Hello,
> 
> I am investigating the current usage of kernel crypto-libraries in the
> SCTP code, considering to adopt the same crypto framework for the
> MPTCP implementation.
> 
> In sm_make_chunk.c, the crypto function "crypto_hash_setkey" is called
> in an atomic context, despite the fact that this function CAN invoke a
> GFP_KERNEL (sleeping) memory allocation. Calling a sleeping function
> from an atomic context can end up in deadlock. Has this factor been
> considered when adding the crypto functions into the SCTP code or has
> it been safely handled/verified in any way?

That code has been in use since the very beginning and we've never seen
any atomicity issues.  I think the reason for this is that we are only
using the sha1 hash code which doesn't seem to provide its own setkey
function.  What I think it's using is the hmac version of setkey (I could
be wrong here...) and that doesn't actually allocate any memory.

-vlad

> 
> 
> Thanks,
> Fabrizio
> --
> To unsubscribe from this list: send the line "unsubscribe linux-sctp" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>