While working on the cryptd request reordering problem, I noticed
an anomaly where kernel threads are normally allowed to use simd
per may_use_simd, but as soon as you disable softirqs, they suddenly
lose that ability for no good reason.
The problem is that in_interrupt does not distinguish
On 14 November 2014 16:43, Herbert Xu herb...@gondor.apana.org.au wrote:
While working on the cryptd request reordering problem, I noticed
an anomaly where kernel threads are normally allowed to use simd
per may_use_simd, but as soon as you disable softirqs, they suddenly
lose that ability for
Use the new memzero_explicit function to cleanup sensitive data.
Signed-off-by: Tadeusz Struk tadeusz.st...@intel.com
---
drivers/crypto/qat/qat_common/qat_algs.c | 36 ++
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git
This prefixes all crypto module loading with crypto- so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:
https://lkml.org/lkml/2013/3/4/70
Signed-off-by: Kees Cook keesc...@chromium.org
---
arch/arm/crypto/aes_glue.c
On Fri, Nov 14, 2014 at 05:17:05PM +0100, Ard Biesheuvel wrote:
On 14 November 2014 16:43, Herbert Xu herb...@gondor.apana.org.au wrote:
While working on the cryptd request reordering problem, I noticed
an anomaly where kernel threads are normally allowed to use simd
per may_use_simd, but
On Wed, Nov 12, 2014 at 09:41:38AM +0100, Steffen Klassert wrote:
Everything below the local_bh_enable() should not run in atomic context
as the subsequent functions may set the CRYPTO_TFM_REQ_MAY_SLEEP flag.
Actually I'm thinking of doing exactly that (disabling softirq in
cryptd) to fix the
Le 15/11/2014 00:59, Andrew Bresticker a écrit :
Hi James,
+
+struct img_hash_drv {
+ struct list_head dev_list;
+ spinlock_t lock;
+};
+
+static struct img_hash_drv img_hash = {
+ .dev_list = LIST_HEAD_INIT(img_hash.dev_list),
+ .lock =
