On 1/3/2018 8:07 PM, Logan Gunthorpe wrote:
> Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64
> functions in non-64bit cases in favour of the new common
> io-64-nonatomic-lo-hi header.
>
> Signed-off-by: Logan Gunthorpe
> Cc: Andy Shevchenko
> Cc: Horia Geantă
> Cc: Dan Dougla
While testing other changes, I discovered that gcc-7.2.1 produces badly
optimized code for aes_encrypt/aes_decrypt. This is especially true when
CONFIG_UBSAN_SANITIZE_ALL is enabled, where it leads to extremely
large stack usage that in turn might cause kernel stack overflows:
crypto/aes_generic.c
On Wed, Jan 3, 2018 at 6:36 PM, Ard Biesheuvel
wrote:
> On 3 January 2018 at 16:37, Arnd Bergmann wrote:
>> On Fri, Dec 22, 2017 at 4:47 PM, Ard Biesheuvel
>> wrote:
>>
>> A minimal patch would be to disable UBSAN specifically for aes-generic.c
>> for gcc-7.2+ but not gcc-8 to avoid the potenti
Signed-off-by: Corentin Labbe
---
Documentation/crypto/crypto_engine.rst | 46 ++
1 file changed, 46 insertions(+)
create mode 100644 Documentation/crypto/crypto_engine.rst
diff --git a/Documentation/crypto/crypto_engine.rst
b/Documentation/crypto/crypto_engine.
Hello
The current crypto_engine support only ahash and ablkcipher request.
My first patch which try to add skcipher was Nacked, it will add too many
functions
and adding other algs(aead, asymetric_key) will make the situation worst.
This patchset remove all algs specific stuff and now only proce
The crypto engine could actually only enqueue hash and ablkcipher request.
This patch permit it to enqueue any type of crypto_async_request.
Signed-off-by: Corentin Labbe
---
crypto/crypto_engine.c | 230
include/crypto/engine.h | 59 +++
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/virtio/virtio_crypto_algs.c | 10 +++---
drivers/crypto/virtio/virtio_crypto_common.h | 3 +--
drivers/crypto/virtio/virtio_crypto_core.c | 3 ---
3 files changed, 8 insertions(
This patch convert the driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/omap-aes.c | 17 +
drivers/crypto/omap-aes.h | 3 +++
drivers/crypto/omap-des.c | 20
3 files changed, 32 insertions(+), 8 deletions(-)
diff --git a
This patch convert the stm32-hash driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/stm32/stm32-hash.c | 18 +-
1 file changed, 13 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-hash.c
b/drivers/crypto/stm32/stm32-hash.
This patch convert the stm32-cryp driver to the new crypto engine API.
Signed-off-by: Corentin Labbe
---
drivers/crypto/stm32/stm32-cryp.c | 21 -
1 file changed, 16 insertions(+), 5 deletions(-)
diff --git a/drivers/crypto/stm32/stm32-cryp.c
b/drivers/crypto/stm32/stm32-cry
On Wed, Jan 03, 2018 at 12:58:02AM -0800, syzbot wrote:
> Hello,
>
> syzkaller hit the following crash on
> 72bca2084a21edda74b802bc076083d5951f67b4
> git://git.kernel.org/pub/scm/linux/kernel/git/davem/net-next.git/master
> compiler: gcc (GCC) 7.1.1 20170620
> .config is attached
> Raw console ou
From: Eric Biggers
Similar to what was done for the hash API, update the skcipher API to
track whether each transform has been keyed, and reject
encryption/decryption if a key is needed but one hasn't been set.
This isn't as important as the equivalent fix for the hash API because
symmetric ciph
From: Eric Biggers
Now that the crypto API prevents a keyed hash from being used without
setting the key, there's no need for GHASH to do this check itself.
Signed-off-by: Eric Biggers
---
crypto/ghash-generic.c | 6 --
1 file changed, 6 deletions(-)
diff --git a/crypto/ghash-generic.c b/
From: Eric Biggers
Currently, almost none of the keyed hash algorithms check whether a key
has been set before proceeding. Some algorithms are okay with this and
will effectively just use a key of all 0's or some other bogus default.
However, others will severely break, as demonstrated using
"hm
From: Eric Biggers
We need to consistently enforce that keyed hashes cannot be used without
setting the key. To do this we need a reliable way to determine whether
a given hash algorithm is keyed or not. AF_ALG currently does this by
checking for the presence of a ->setkey() method. However, t
From: Eric Biggers
Since Poly1305 requires a nonce per invocation, the Linux kernel
implementations of Poly1305 don't use the crypto API's keying mechanism
and instead expect the key and nonce as the first 32 bytes of the data.
But ->setkey() is still defined as a stub returning an error code. T
From: Eric Biggers
Similar to what was done for the hash API, update the AEAD API to track
whether each transform has been keyed, and reject encryption/decryption
if a key is needed but one hasn't been set.
This isn't quite as important as the equivalent fix for the hash API
because AEADs always
From: Eric Biggers
When the mcryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the mcryptd instance. This change
is necessary for mcryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Cc
From: Eric Biggers
This series updates the crypto API to consistently prevent using keyed
algorithms without setting the key. Currently this is prevented for
AF_ALG but not for other crypto API users, which is very problematic for
other places in the kernel where userspace can specify a hash alg
From: Eric Biggers
Templates that use an shash spawn can use crypto_shash_alg_has_setkey()
to determine whether the underlying algorithm requires a key or not.
But there was no corresponding function for ahash spawns. Add it.
Note that the new function actually has to support both shash and aha
From: Eric Biggers
When the cryptd template is used to wrap an unkeyed hash algorithm,
don't install a ->setkey() method to the cryptd instance. This change
is necessary for cryptd to keep working with unkeyed hash algorithms
once we start enforcing that ->setkey() is called when present.
Cc: s
Now that ioread64 and iowrite64 are available in io-64-nonatomic,
we can remove the hack at the top of ntb_hw_intel.c and replace it
with an include.
Signed-off-by: Logan Gunthorpe
Reviewed-by: Andy Shevchenko
Acked-by: Dave Jiang
Acked-by: Allen Hubbe
Acked-by: Jon Mason
# Please enter the
This is just a resend. I haven't recieved any additional feedback in a number
of version and the patchset has been around for a couple kernel cycles.
It would be nice if someone would take a look at getting this merged.
This cleanup was originally requested by Greg after he reviewed my
Switchtec N
Subsequent patches in this series makes use of the readq and writeq
defines in iomap.h. However, as is, they get missed on the powerpc
platform seeing the include comes before the define. This patch
moves the include down to fix this.
Signed-off-by: Logan Gunthorpe
Acked-by: Michael Ellerman
Rev
In order to provide non-atomic functions for io{read|write}64 that will
use readq and writeq when appropriate. We define a number of variants
of these functions in the generic iomap that will do non-atomic
operations on pio but atomic operations on mmio.
These functions are only defined if readq a
This patch adds generic io{read|write}64[be]{_lo_hi|_hi_lo} macros if
they are not already defined by the architecture. (As they are provided
by the generic iomap library).
The patch also points io{read|write}64[be] to the variant specified by the
header name.
This is because new drivers are enco
These functions will be introduced into the generic iomap.c so
they can deal with PIO accesses in hi-lo/lo-hi variants. Thus,
the powerpc version of iomap.c will need to provide the same
functions even though, in this arch, they are identical to the
regular io{read|write}64 functions.
Signed-off-b
Add a check to ensure iowrite64 is only used if it is atomic.
It was decided in [1] that the tilcdc driver should not be using an
atomic operation (so it was left out of this patchset). However, it turns
out that through the drm code, a nonatomic header is actually included:
include/linux/io-64-n
Clean up the ifdefs which conditionally defined the io{read|write}64
functions in favour of the new common io-64-nonatomic-lo-hi header.
Signed-off-by: Logan Gunthorpe
Cc: Jon Mason
---
drivers/ntb/hw/mscc/ntb_hw_switchtec.c | 30 +-
1 file changed, 1 insertion(+), 2
Clean up the extra ifdefs which defined the wr_reg64 and rd_reg64
functions in non-64bit cases in favour of the new common
io-64-nonatomic-lo-hi header.
Signed-off-by: Logan Gunthorpe
Cc: Andy Shevchenko
Cc: Horia Geantă
Cc: Dan Douglass
Cc: Herbert Xu
Cc: "David S. Miller"
---
drivers/cryp
On 3 January 2018 at 16:37, Arnd Bergmann wrote:
> On Fri, Dec 22, 2017 at 4:47 PM, Ard Biesheuvel
> wrote:
>> On 21 December 2017 at 13:47, PrasannaKumar Muralidharan
>> wrote:
>>> On 21 December 2017 at 17:52, Ard Biesheuvel
>>> wrote:
On 21 December 2017 at 10:20, Arnd Bergmann wrote
On Fri, Dec 22, 2017 at 4:47 PM, Ard Biesheuvel
wrote:
> On 21 December 2017 at 13:47, PrasannaKumar Muralidharan
> wrote:
>> On 21 December 2017 at 17:52, Ard Biesheuvel
>> wrote:
>>> On 21 December 2017 at 10:20, Arnd Bergmann wrote:
>>>
>>> So my vote is to disable UBSAN for all such ciphe
Gilad,
On Wed, Jan 3, 2018 at 2:35 PM, Gilad Ben-Yossef wrote:
> Replace verbatim GPL v2 copy with SPDX tag.
>
> Signed-off-by: Gilad Ben-Yossef
> --- a/drivers/staging/ccree/cc_crypto_ctx.h
> +++ b/drivers/staging/ccree/cc_crypto_ctx.h
> @@ -1,18 +1,5 @@
> -/*
> - * Copyright (C) 2012-2017 A
Replace verbatim GPL v2 copy with SPDX tag.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/Kconfig| 2 ++
drivers/staging/ccree/Makefile | 2 ++
drivers/staging/ccree/cc_crypto_ctx.h| 17 ++---
drivers/staging/ccree/cc_debugfs.c | 17 ++---
The ccree driver was allocating memory using GFP_KERNEL flag
always, ignoring the flags set in the crypto request. Fix it
by choosing gfp flags based on crypto request flags.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_buffer_mgr.c | 19 +++--
drivers/staging/ccree/ssi_
The ccree driver was using a DMA operation to copy larval digest
from the ccree SRAM to RAM. Replace it with a simple memcpy.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_driver.c | 2 +
drivers/staging/ccree/ssi_hash.c | 121 -
drivers/st
Fold the 2 macro defined in dx_reg_common.h into the file they
are used in and delete the file.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/cc_crypto_ctx.h | 4 ++--
drivers/staging/ccree/dx_reg_common.h | 13 -
drivers/staging/ccree/ssi_driver.h| 5 +++--
3 files
Remove bogus GFP_DMA flag from memory allocations. ccree driver
does not operate over an ISA or similar limited bus.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_cipher.c | 2 +-
drivers/staging/ccree/ssi_hash.c | 15 ++-
2 files changed, 7 insertions(+), 10 delet
The send_request() function was handling both synchronous
and asynchronous invocations, but were not handling
the asynchronous case, which may be called in an atomic
context, properly as it was sleeping.
Start to fix the problem by breaking up the two use
cases to separate functions calling a comm
Crypto API tfm providers are required to provide a backlog
service, if so indicated, that queues up requests in the case
of the provider being busy and processing them later.
The ccree driver did not provide this facility. Add it now.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ss
Replace ugly ifdefs with some inline macros and Makefile magic
for optionally including power management related code for
better readability.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/Makefile | 3 ++-
drivers/staging/ccree/ssi_pm.c | 9 +---
drivers/stagi
If we are asked for number of entries of an offset bigger than the
sg list we should not crash.
Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_buffer_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_buff
PM suspend returning a none zero value is not an error. It simply
indicates a suspend is not advised right now so don't treat it as
an error.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_request_mgr.c | 8 +---
1 file changed, 1 insertion(+), 7 deletions(-)
diff --git a/dri
Remove unused struct field.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_hash.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi_hash.c
index e05c87d..4e11b5d 100644
--- a/drivers/staging/ccree/ssi_hash.c
+++ b/drive
Move to allocating the buffers needed for requests as part of
the request structure instead of malloc'ing each one on it's
own, making for simpler (and more efficient) code.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_hash.c | 68
driver
The ccree hash code is using a double buffer to hold data
for processing but manages the buffers and their associated
data count in two separate fields and uses a predicate to
chose which to use.
Move to using a proper 2 members array for a much cleaner code.
Signed-off-by: Gilad Ben-Yossef
---
hash_init was mapping DMA memory that were then being unmap in
hash_digest/final/finup callbacks, which is against the Crypto API
usage rules (see discussion at
https://www.mail-archive.com/linux-crypto@vger.kernel.org/msg30077.html)
Fix it by moving all buffer mapping/unmapping or each Crypto API
Fix indentation of some function params in hash code for
better readability.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_hash.c | 46 +---
1 file changed, 20 insertions(+), 26 deletions(-)
diff --git a/drivers/staging/ccree/ssi_hash.c b/driv
Remove include files not needed for compilation.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/cc_aead.c| 7 ---
drivers/staging/ccree/cc_buffer_mgr.c | 6 --
drivers/staging/ccree/cc_cipher.c | 4
drivers/staging/ccree/cc_driver.c | 31
Update TODO to reflect work done
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/TODO | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/TODO b/drivers/staging/ccree/TODO
index 6d8702b..b8e163d 100644
--- a/drivers/staging/ccree/TODO
+++ b/drivers
Add the missing include of include file with function declarations.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/cc_debugfs.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/drivers/staging/ccree/cc_debugfs.c
b/drivers/staging/ccree/cc_debugfs.c
index 363a0ef..e07cbb1 100644
--
Fold common code in hash call into service functions.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_hash.c | 339 ++-
1 file changed, 116 insertions(+), 223 deletions(-)
diff --git a/drivers/staging/ccree/ssi_hash.c b/drivers/staging/ccree/ssi
We were allocating buffers using sizeof(*struct->field) where field was
type void. Fix it by having a local variable with the real type.
Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_ivgen.c| 9 -
drivers/staging/ccree/ssi_sram_mgr.c | 9 ++
Put pointer next to var name as per coding style.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_request_mgr.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_request_mgr.c
b/drivers/staging/ccree/ssi_request_mgr.c
index 01f4756..8237
If we ran out of DMA pool buffers, we get into the unmap
code path with a NULL before. Deal with this by checking
the virtual mapping is not NULL.
Cc: sta...@vger.kernel.org
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_buffer_mgr.c | 3 ++-
1 file changed, 2 insertions(+), 1 del
This reverts commit c5f39d07860c ("staging: ccree: fix leak of import()
after init()") and commit aece09024414 ("staging: ccree: Uninitialized
return in ssi_ahash_import()").
This is the wrong solution and ends up relying on uninitialized memory,
although it was not obvious to me at the time.
Cc:
Remove the unused monitor_desc field.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/ssi_request_mgr.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/drivers/staging/ccree/ssi_request_mgr.c
b/drivers/staging/ccree/ssi_request_mgr.c
index ac6846f..18e2e1d 100644
--- a/drivers/stag
The debugfs global init and exit functions were missing
__init and __exit tags, potentially wasting memory.
Fix it by properly tagging them.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/cc_debugfs.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/drivers/stag
Fold the two remaining enum in hash defs into the queue defs
that are using them and delete the hash defs include file.
Signed-off-by: Gilad Ben-Yossef
---
drivers/staging/ccree/cc_hw_queue_defs.h | 13 +
drivers/staging/ccree/hash_defs.h| 23 ---
drivers/
The usual combo of code cleanups and fixes.
The highlights are:
- Use SPDX for all driver copyright/license
- Make ccree compliant with crypto API handling of backlog requests
- Make ccree compliant with Crypto API rules of resource alloc/release
- Settle on a single coherent file naming conventio
Hi
On Wed, Jan 3, 2018 at 11:26 AM, Arnd Bergmann wrote:
> The global array clashes with an existing symbol of the same name:
>
> drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of
> `debug_regs'
> drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
>
> We should fix b
The global array clashes with an existing symbol of the same name:
drivers/staging/ccree/cc_debugfs.o:(.data+0x0): multiple definition of
`debug_regs'
drivers/mmc/host/s3cmci.o:(.data+0x70): first defined here
We should fix both, this one addresses the ccree driver by removing
the symbol from th
Hi Colin,
On Tue, Jan 02, 2018 at 02:34:10PM +, Colin King wrote:
>
> /* Called with ring's lock taken */
> -int safexcel_try_push_requests(struct safexcel_crypto_priv *priv, int ring,
> -int reqs)
> +static int safexcel_try_push_requests(struct safexcel_crypto_p
63 matches
Mail list logo
