Linux Kernel https://git.stealer.net/cgit.cgi/user/sven/linux.git/atom?h=v4.4.63 2017-03-26T10:13:17Z 2017-03-26T10:13:17Z Wang, Rui Y rui.y.wang@intel.com 2016-01-27T09:08:36Z urn:sha1:f8c07cbc2e72a7e26bff8c5823f6e045eeeb4e16 commit ddef482420b1ba8ec45e6123a7e8d3f67b21e5e3 upstream. mcryptd_create_hash() fails by returning -EINVAL, causing any driver using mcryptd to fail to load. It is because it needs to set its statesize properly. Signed-off-by: Rui Wang <rui.y.wang@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Cc: Sumit Semwal <sumit.semwal@linaro.org> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2016-12-15T16:49:22Z tim tim.c.chen@linux.intel.com 2016-12-05T19:46:31Z urn:sha1:9a3baed9103bc413a5e98e13e31cd8ae7c0b5563 commit 48a992727d82cb7db076fa15d372178743b1f4cd upstream. Algorithms not compatible with mcryptd could be spawned by mcryptd with a direct crypto_alloc_tfm invocation using a "mcryptd(alg)" name construct. This causes mcryptd to crash the kernel if an arbitrary "alg" is incompatible and not intended to be used with mcryptd. It is an issue if AF_ALG tries to spawn mcryptd(alg) to expose it externally. But such algorithms must be used internally and not be exposed. We added a check to enforce that only internal algorithms are allowed with mcryptd at the time mcryptd is spawning an algorithm. Link: http://marc.info/?l=linux-crypto-vger&m=148063683310477&w=2 Reported-by: Mikulas Patocka <mpatocka@redhat.com> Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org> 2015-03-31T13:21:13Z Stephan Mueller smueller@chronox.de 2015-03-30T20:10:58Z urn:sha1:f52bbf55d1957b9ab279998dd71ed1c89b36e3a7 The mcryptd is used as a wrapper around internal ciphers. Therefore, the mcryptd must process the internal cipher by marking mcryptd as internal if the underlying cipher is an internal cipher. Signed-off-by: Stephan Mueller <smueller@chronox.de> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 2014-11-26T12:06:30Z Kees Cook keescook@chromium.org 2014-11-25T00:32:38Z urn:sha1:4943ba16bbc2db05115707b3ff7b4874e9e3c560 This adds the module loading prefix "crypto-" to the template lookup as well. For example, attempting to load 'vfat(blowfish)' via AF_ALG now correctly includes the "crypto-" prefix at every level, correctly rejecting "vfat": net-pf-38 algif-hash crypto-vfat(blowfish) crypto-vfat(blowfish)-all crypto-vfat Reported-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Kees Cook <keescook@chromium.org> Acked-by: Mathias Krause <minipli@googlemail.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 2014-08-26T06:40:39Z Fengguang Wu fengguang.wu@intel.com 2014-08-26T06:40:39Z urn:sha1:1f6e97f68b908a09c6ff74d4f1310e9ab8df0e64 CC: Tim Chen <tim.c.chen@linux.intel.com> CC: Herbert Xu <herbert@gondor.apana.org.au> Signed-off-by: Fengguang Wu <fengguang.wu@intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au> 2014-08-25T12:32:25Z Tim Chen tim.c.chen@linux.intel.com 2014-07-31T17:29:51Z urn:sha1:1e65b81a90df50bf450193065cc9073b706b8dda This patch introduces the multi-buffer crypto daemon which is responsible for submitting crypto jobs in a work queue to the responsible multi-buffer crypto algorithm. The idea of the multi-buffer algorihtm is to put data streams from multiple jobs in a wide (AVX2) register and then take advantage of SIMD instructions to do crypto computation on several buffers simultaneously. The multi-buffer crypto daemon is also responsbile for flushing the remaining buffers to complete the computation if no new buffers arrive for a while. Signed-off-by: Tim Chen <tim.c.chen@linux.intel.com> Signed-off-by: Herbert Xu <herbert@gondor.apana.org.au>