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@xxxxxxxxxxxxxxxxxxx>: > Fabrizio Demaria <fabrizio.f.demaria@xxxxxxxxx> 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@xxxxxxxxxxxxxxxxxxx> > Home Page: http://gondor.apana.org.au/~herbert/ > PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
