"crypto_hash_setkey" call from atomic context

"crypto_hash_setkey" call from atomic context

[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.
Is there a way to make sure that “crypto_hash_setkey” can be safely
called in an atomic context, considering all the possible code-paths
followed by the function?

Thanks,
Fabrizio

Re: "crypto_hash_setkey" call from atomic context

[Herbert Xu]

Fabrizio Demaria <fabrizio.f.demaria@gmail.com> 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.
> Is there a way to make sure that “crypto_hash_setkey” can be safely
> called in an atomic context, considering all the possible code-paths
> followed by the function?

Indeed, in general setkey should not be invoked in atomic contexts.
The only exception would be extremely simple hashes such as CRC.

Keys should be setup before hand.  So SCTP needs to be fixed.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: "crypto_hash_setkey" call from atomic context

[Fabrizio Demaria]

In our MPTCP implementation we handled the setkey problem by
pre-allocating a properly aligned key's buffer right after
"crypto_alloc_hash", outside atomic context [1]. Would this workaround
be enough to guarantee that "crypto_hash_setkey" can be safely called
in atomic contexts? Is it always the case that "crypto_hash_setkey"
calls "crypto_shash_setkey"?

Thanks,
Fabrizio

[1] https://github.com/multipath-tcp/mptcp_net-next/commit/06e7644bdac1ac6e97767bc714586fbfadcdeaa8

2015-12-11 8:42 GMT+01:00 Herbert Xu <herbert@gondor.apana.org.au>:
> Fabrizio Demaria <fabrizio.f.demaria@gmail.com> 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.
>> Is there a way to make sure that “crypto_hash_setkey” can be safely
>> called in an atomic context, considering all the possible code-paths
>> followed by the function?
>
> Indeed, in general setkey should not be invoked in atomic contexts.
> The only exception would be extremely simple hashes such as CRC.
>
> Keys should be setup before hand.  So SCTP needs to be fixed.
>
> Cheers,
> --
> Email: Herbert Xu <herbert@gondor.apana.org.au>
> Home Page: http://gondor.apana.org.au/~herbert/
> PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt

Re: "crypto_hash_setkey" call from atomic context

[Herbert Xu]

On Mon, Dec 14, 2015 at 09:53:03AM +0100, Fabrizio Demaria wrote:
> In our MPTCP implementation we handled the setkey problem by
> pre-allocating a properly aligned key's buffer right after
> "crypto_alloc_hash", outside atomic context [1]. Would this workaround
> be enough to guarantee that "crypto_hash_setkey" can be safely called
> in atomic contexts? Is it always the case that "crypto_hash_setkey"
> calls "crypto_shash_setkey"?

First of all don't use crypto_hash_* in new code.  It is obsolete.
Instead use shash or ahash as appropirate.

The proper way to manage keys is to set them when you allocate the
tfm.  You should use a different tfm for each key.

Cheers,
-- 
Email: Herbert Xu <herbert@gondor.apana.org.au>
Home Page: http://gondor.apana.org.au/~herbert/
PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt