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 = __SPI
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 th
On Fri, Nov 14, 2014 at 05:17:05PM +0100, Ard Biesheuvel wrote:
> On 14 November 2014 16:43, Herbert Xu 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
Hi James,
On Mon, Nov 10, 2014 at 4:10 AM, James Hartley wrote:
> This adds support for the Imagination Technologies hash
> accelerator that provides hardware acceleration for
> SHA1 SHA224 SHA256 and MD5 Hashes.
>
> Signed-off-by: James Hartley
It's going to take me a little longer to get thro
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
---
arch/arm/crypto/aes_glue.c | 4 ++--
Use the new memzero_explicit function to cleanup sensitive data.
Signed-off-by: Tadeusz Struk
---
drivers/crypto/qat/qat_common/qat_algs.c | 36 ++
1 file changed, 22 insertions(+), 14 deletions(-)
diff --git a/drivers/crypto/qat/qat_common/qat_algs.c
b/drivers/cr
On 14 November 2014 16:43, Herbert Xu 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 no good reason.
>
> The
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 betwee
