On 17/10/2019 07:06, Corentin Labbe wrote:
> This patch adds support for the amlogic GXL cryptographic offloader present
> on GXL SoCs.
>
> This driver supports AES cipher in CBC/ECB mode.
>
> Signed-off-by: Corentin Labbe
> ---
> drivers/crypto/Kconfig | 2 +
> drivers/c
On Wed, Oct 16, 2019 at 11:35:07PM +1100, Herbert Xu wrote:
> > > Eric Biggers (3):
> > > crypto: s390/aes - convert to skcipher API
> > > crypto: s390/paes - convert to skcipher API
> > > crypto: s390/des - convert to skcipher API
> > >
> > > arch/s390/crypto/aes_s390.c | 609
On Wed, Oct 16, 2019 at 06:46:09PM +0800, YueHaibing wrote:
> External E-Mail
>
>
> Use devm_platform_ioremap_resource() to simplify the code a bit.
> This is detected by coccinelle.
>
> Signed-off-by: YueHaibing
Acked-by: Ludovic Desroches
Thanks
> ---
> drivers/char/hw_random/atmel-rng.c
On Mon, 14 Oct 2019 at 11:17, David Sterba wrote:
>
> Test vectors for blake2b with various digest sizes. As the algorithm is
> the same up to the digest calculation, the key and input data length is
> distributed in a way that tests all combinanions of the two over the
> digest sizes.
>
> Based o
On 15/10/2019 20:28, Tony Lindgren wrote:
* Ard Biesheuvel [191014 12:20]:
Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
dated 20 august 2015 introduced the new skcipher API which is supposed to
replace both blkcipher and ablkcipher. While all consumers of the API
On Thu, 17 Oct 2019 at 12:25, Tero Kristo wrote:
>
> On 15/10/2019 20:28, Tony Lindgren wrote:
> > * Ard Biesheuvel [191014 12:20]:
> >> Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
> >> dated 20 august 2015 introduced the new skcipher API which is supposed to
> >>
On 17/10/2019 13:45, Ard Biesheuvel wrote:
On Thu, 17 Oct 2019 at 12:25, Tero Kristo wrote:
On 15/10/2019 20:28, Tony Lindgren wrote:
* Ard Biesheuvel [191014 12:20]:
Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
dated 20 august 2015 introduced the new skcipher
On Thu, 17 Oct 2019 at 13:25, Tero Kristo wrote:
>
> On 17/10/2019 13:45, Ard Biesheuvel wrote:
> > On Thu, 17 Oct 2019 at 12:25, Tero Kristo wrote:
> >>
> >> On 15/10/2019 20:28, Tony Lindgren wrote:
> >>> * Ard Biesheuvel [191014 12:20]:
> Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-
On 17/10/2019 14:56, Ard Biesheuvel wrote:
On Thu, 17 Oct 2019 at 13:25, Tero Kristo wrote:
On 17/10/2019 13:45, Ard Biesheuvel wrote:
On Thu, 17 Oct 2019 at 12:25, Tero Kristo wrote:
On 15/10/2019 20:28, Tony Lindgren wrote:
* Ard Biesheuvel [191014 12:20]:
Commit 7a7ffe65c8c5 ("crypto
Hi,
This series fixes a number of bugs with omap crypto implementation.
These have become evident with the changes to the cryptomanager, where
it adds some new test cases and modifies some existing, namely the split
update tests. Also, while fixing the cryptomanager induced bugs, some
other surfac
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-sham.c | 2 ++
1 file changed, 2 insertions(+)
diff --git a/drivers/crypto/omap-sham.c b/drivers/crypto/om
Current buffer handling logic fails in a case where the buffer contains
existing data from previous update which is divisible by block size.
This results in a block size of data to be left missing from the sg
list going out to the hw accelerator, ending up in stalling the
crypto accelerator driver
The driver removal should also cleanup the created sysfs group. If not,
the driver fails the subsequent probe as the files exist already. Also,
drop a completely unnecessary pointer assignment from the removal
function at the same time.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes.c |
Fix a corner case where only authdata is generated, without any provided
assocdata / cryptdata. Passing the empty scatterlists to OMAP AES core driver
in this case would confuse it, failing to map DMAs.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes-gcm.c | 22 ++
1 f
Currently omap-des driver does not copy end result IV out at all. This
is evident with the additional checks done at the crypto test manager.
Fix by copying out the IV values from HW.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-des.c | 6 ++
1 file changed, 6 insertions(+)
diff --git
Currently omap-aes driver does not copy end result IV out at all. This
is evident with the additional checks done at the crypto test manager.
Fix by copying out the IV values from HW.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes.c | 12
1 file changed, 12 insertions(+)
di
The updated crypto manager finds a couple of new bugs from the omap-sham
driver. Basically the split update cases fail to calculate the amount of
data to be sent properly, leading into failed results and hangs with the
hw accelerator.
To fix these, the buffer handling needs to be fixed, but we do
Aligned data cleanup is using wrong pointers in the cleanup calls. Most
of the time these are right, but can cause mysterious problems in some
cases. Fix to use the same pointers that were used with the align call.
Signed-off-by: Tero Kristo
---
drivers/crypto/omap-aes.c | 4 ++--
1 file changed
Currently crypto_wait_req waits indefinitely for an async crypto request
to complete. This is bad as it can cause for example the crypto test
manager to hang without any notification as to why it has happened.
Instead of waiting indefinitely, add a 1 second timeout to the call,
and provide a warnin
When using huge data amount, allocating free pages fails as the kernel
isn't able to process get_free_page requests larger than MAX_ORDER.
Also, the DMA subsystem has an inherent limitation that data size
larger than some 2MB can't be handled properly. In these cases,
split up the data instead to s
On Thu, 17 Oct 2019 at 00:40, James Bottomley
wrote:
>
> On Wed, 2019-10-16 at 19:25 +0300, Jarkko Sakkinen wrote:
> > On Wed, Oct 16, 2019 at 08:34:12AM -0400, James Bottomley wrote:
> > > reversible ciphers are generally frowned upon in random number
> > > generation, that's why the krng uses ch
On Thu, 2019-10-17 at 18:22 +0530, Sumit Garg wrote:
> On Thu, 17 Oct 2019 at 00:40, James Bottomley
> wrote:
> >
> > On Wed, 2019-10-16 at 19:25 +0300, Jarkko Sakkinen wrote:
> > > On Wed, Oct 16, 2019 at 08:34:12AM -0400, James Bottomley wrote:
> > > > reversible ciphers are generally frowned u
Hi Arnd,
Sorry for not responding earlier, but I've been very busy lately.
So I'm looking at this now for the first time.
> -Original Message-
> From: Arnd Bergmann
> Sent: Monday, September 30, 2019 2:15 PM
> To: Antoine Tenart ; Herbert Xu
> ;
> David S. Miller ; Bjorn Helgaas
> Cc:
On Mon, Sep 30, 2019 at 11:52 AM Tian Tao wrote:
>
> This patch fixes the following warnings:
> drivers/crypto/ccree/cc_aead.c:630:5-12: WARNING: Unsigned expression
> compared with zero: seq_len > 0
Thank you very much for the patch. Please accept my apologies that it
took me some time to respon
On Thu, Oct 17, 2019 at 3:26 PM Pascal Van Leeuwen
wrote:
> > /* Register PCI driver */
> > - pcireg_rc = pci_register_driver(&safexcel_pci_driver);
> > -#endif
> > + ret = pci_register_driver(&safexcel_pci_driver);
> >
> > -#if IS_ENABLED(CONFIG_OF)
> > /* Register platform d
On 16.10.19 19:05, Eric Biggers wrote:
> On Tue, Oct 15, 2019 at 01:31:39PM +0200, Harald Freudenberger wrote:
>> On 12.10.19 22:18, Eric Biggers wrote:
>>> From: Eric Biggers
>>>
>>> Convert the glue code for the S390 CPACF protected key implementations
>>> of AES-ECB, AES-CBC, AES-XTS, and AES-C
> -Original Message-
> From: Arnd Bergmann
> Sent: Thursday, October 17, 2019 3:48 PM
> To: Pascal Van Leeuwen
> Cc: Antoine Tenart ; Herbert Xu
> ;
> David S. Miller ; Bjorn Helgaas ;
> Pascal van Leeuwen
> ; Kelsey Skunberg ; linux-
> cry...@vger.kernel.org; linux-ker...@vger.kernel.o
Hi,
On 14.10.2019 14:18, Ard Biesheuvel wrote:
> Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
> dated 20 august 2015 introduced the new skcipher API which is supposed to
> replace both blkcipher and ablkcipher. While all consumers of the API have
> been converted lon
On Thu, 17 Oct 2019 at 17:18, Kamil Konieczny wrote:
>
> Hi,
>
> On 14.10.2019 14:18, Ard Biesheuvel wrote:
> > Commit 7a7ffe65c8c5 ("crypto: skcipher - Add top-level skcipher interface")
> > dated 20 august 2015 introduced the new skcipher API which is supposed to
> > replace both blkcipher and a
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of
> Pascal Van Leeuwen
> Sent: Tuesday, October 8, 2019 9:57 AM
> To: Ard Biesheuvel
> Cc: YueHaibing ; herb...@gondor.apana.org.au;
> da...@davemloft.net;
> pascalv...@gmail.com; antoine.ten...@bootlin.com;
>
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of
> Randy Dunlap
> Sent: Wednesday, October 9, 2019 5:50 PM
> To: LKML ; Linux Crypto Mailing List cry...@vger.kernel.org>
> Cc: Antoine Tenart ; Herbert Xu
> ; David Miller
> Subject: [PATCH -next] crypto: ins
Always take the zero length hash value for SM3 from the local constant
to avoid a reported build error when SM3 is configured to be a module.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel_hash.c | 8 ++--
1 file changed, 2 insertions(+), 6 deletions(-)
diff --g
safexcel_pci_remove() is only used locally in the module and not exported,
so added a static function specifier.
This fixes a sparse issue reported by Ben Dooks.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
d
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Ben
> Dooks (Codethink)
> Sent: Wednesday, October 16, 2019 1:45 PM
> To: linux-ker...@lists.codethink.co.uk
> Cc: Ben Dooks (Codethink) ; Antoine Tenart
> ; Herbert Xu ; David
> S. Miller
> ; linux-crypto@v
> -Original Message-
> From: linux-crypto-ow...@vger.kernel.org
> On Behalf Of Ben
> Dooks (Codethink)
> Sent: Wednesday, October 16, 2019 1:50 PM
> To: linux-ker...@lists.codethink.co.uk
> Cc: Ben Dooks (Codethink) ; Antoine Tenart
> ; Herbert Xu ; David
> S. Miller
> ; linux-crypto@vge
On Wed, Oct 16, 2019 at 03:10:29PM -0400, James Bottomley wrote:
> On Wed, 2019-10-16 at 19:25 +0300, Jarkko Sakkinen wrote:
> > On Wed, Oct 16, 2019 at 08:34:12AM -0400, James Bottomley wrote:
> > > reversible ciphers are generally frowned upon in random number
> > > generation, that's why the krn
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/chacha-scalar-core.S | 461
1 file changed, 461 insertions(+)
diff --git a/arch/arm/crypto/chacha-scalar-core.S
b/arch/arm/crypto/chacha-scalar-core.S
new file mode 100644
index ..2140319b64a0
--- /dev/null
+++ b
Expose the accelerated NEON ChaCha routine directly as a symbol
export so that users of the ChaCha library API can use it directly.
Given that calls into the library API will always go through the
routines in this module if it is enabled, switch to static keys
to select the optimal implementation
Wire the existing x86 SIMD ChaCha code into the new ChaCha library
interface, so that users of the library interface will get the
accelerated version when available.
Given that calls into the library API will always go through the
routines in this module if it is enabled, switch to static keys
to
Currently, our generic ChaCha implementation consists of a permute
function in lib/chacha.c that operates on the 64-byte ChaCha state
directly [and which is always included into the core kernel since it
is used by the /dev/random driver], and the crypto API plumbing to
expose it as a skcipher.
In
Depend on the generic ChaCha library routines instead of pulling in the
generic ChaCha skcipher driver, which is more than we need, and makes
managing the dependencies between the generic library, generic driver,
accelerated library and driver more complicated.
While at it, drop the logic to prefe
Expose the accelerated NEON ChaCha routine directly as a symbol
export so that users of the ChaCha library API can use it directly.
Given that calls into the library API will always go through the
routines in this module if it is enabled, switch to static keys
to select the optimal implementation
This integrates the accelerated MIPS 32r2 implementation of ChaCha
into both the API and library interfaces of the kernel crypto stack.
The significance of this is that, in addition to becoming available
as an accelerated library implementation, it can also be used by
existing crypto API code such
In preparation of introducing a set of crypto library interfaces, tidy
up the Makefile and split off the Kconfig symbols into a separate file.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 13 +
lib/crypto/Kconfig | 15 +++
lib/crypto/Makefile | 16
This series implements the crypto library abstractions that are needed to
incorporate WireGuard into the mainline kernel.
Changes since v3:
- Unify the way the generic vs arch libraries are organized between ChaCha20
and Poly1305 on the one hand and Curve25519 and Blake2s on the other.
All are
As suggested by Eric for the Blake2b implementation contributed by
David, introduce a set of test vectors for Blake2s covering different
digest and key sizes.
blake2s-128 blake2s-160 blake2s-224 blake2s-256
---
len=0 | klen=0
From: "Jason A. Donenfeld"
This imports the accelerated MIPS 32r2 ChaCha20 implementation from the
Zinc patch set.
Co-developed-by: René van Dorst
Signed-off-by: René van Dorst
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Ard Biesheuvel
---
arch/mips/crypto/chacha-core.S | 424 +
In preparation of extending the x86 ChaCha driver to also expose the ChaCha
library interface, drop the dependency on the chacha_generic crypto driver
as a non-SIMD fallback, and depend on the generic ChaCha library directly.
This way, we only pull in the code we actually need, without registering
Wire up our newly added Blake2s implementation via the shash API.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig| 4 +
crypto/Makefile | 1 +
crypto/blake2s-generic.c | 171
include/crypto/internal/blake2s.h | 5 +
4 fil
Expose the existing generic Poly1305 code via a init/update/final
library interface so that callers are not required to go through
the crypto API's shash abstraction to access it. At the same time,
make some preparations so that the library implementation can be
superseded by an accelerated arch-sp
Now that all users of generic ChaCha code have moved to the core library,
there is no longer a need for the generic ChaCha skcpiher driver to
export parts of it implementation for reuse by other drivers. So drop
the exports, and make the symbols static.
Signed-off-by: Ard Biesheuvel
---
crypto/c
Remove the dependency on the generic Poly1305 driver. Instead, depend
on the generic library so that we only reuse code without pulling in
the generic skcipher implementation as well.
While at it, remove the logic that prefers the non-SIMD path for short
inputs - this is no longer necessary after
Move the core Poly1305 routines shared between the generic Poly1305
shash driver and the Adiantum and NHPoly1305 drivers into a separate
library so that using just this pieces does not pull in the crypto
API pieces of the generic Poly1305 routine.
In a subsequent patch, we will augment this generi
Implement the arch init/update/final Poly1305 library routines in the
accelerated SIMD driver for x86 so they are accessible to users of
the Poly1305 library interface as well.
Signed-off-by: Ard Biesheuvel
---
arch/x86/crypto/poly1305_glue.c | 57 ++--
crypto/Kconfig
This is a straight import of the OpenSSL/CRYPTOGAMS Poly1305 implementation
for NEON authored by Andy Polyakov, and contributed by him to the OpenSSL
project. The file 'poly1305-armv8.pl' is taken straight from this upstream
GitHub repository [0] at commit ec55a08dc0244ce570c4fc7cade330c60798952f,
In preparation of exposing a Poly1305 library interface directly from
the accelerated x86 driver, align the state descriptor of the x86 code
with the one used by the generic driver. This is needed to make the
library interface unified between all implementations.
Signed-off-by: Ard Biesheuvel
---
Instead of falling back to the generic ChaCha skcipher driver for
non-SIMD cases, use a fast scalar implementation for ARM authored
by Eric Biggers. This removes the module dependency on chacha-generic
altogether, which also simplifies things when we expose the ChaCha
library interface from this mo
From: "Jason A. Donenfeld"
These implementations from Samuel Neves support AVX and AVX-512VL.
Originally this used AVX-512F, but Skylake thermal throttling made
AVX-512VL more attractive and possible to do with negligable difference.
Signed-off-by: Jason A. Donenfeld
Signed-off-by: Samuel Neves
From: "Jason A. Donenfeld"
This contains two formally verified C implementations of the Curve25519
scalar multiplication function, one for 32-bit systems, and one for
64-bit systems whose compiler supports efficient 128-bit integer types.
Not only are these implementations formally verified, but
Expose the generic Curve25519 library via the crypto API KPP interface.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 5 ++
crypto/Makefile | 1 +
crypto/curve25519-generic.c | 93
3 files changed, 99 insertions(+)
diff --git a/crypto/Kconfig
The Curve25519 drivers we will be implementing will perform validation
of the inputs, and in order to ensure that these checks work as expected,
we need to be able to test for expected errors. So implement this in the
KPP test routines in the testmgr framework.
Signed-off-by: Ard Biesheuvel
---
Arnd reports that the 32-bit generic library code for Curve25119 ends
up using an excessive amount of stack space when built with Clang:
lib/crypto/curve25519-fiat32.c:756:6: error: stack frame size
of 1384 bytes in function 'curve25519_generic'
[-Werror,-Wframe-larger-than=]
Let's
In preparation of introducing KPP implementations of Curve25519, import
the set of test cases proposed by the Zinc patch set, but converted to
the KPP format.
Signed-off-by: Ard Biesheuvel
---
crypto/testmgr.c |6 +
crypto/testmgr.h | 1603
2 files changed, 1609 insertio
From: "Jason A. Donenfeld"
The C implementation was originally based on Samuel Neves' public
domain reference implementation but has since been heavily modified
for the kernel. We're able to do compile-time optimizations by moving
some scaffolding around the final function into the header file.
This is a straight import of the OpenSSL/CRYPTOGAMS Poly1305 implementation
for NEON authored by Andy Polyakov, and contributed by him to the OpenSSL
project. The file 'poly1305-armv4.pl' is taken straight from this upstream
GitHub repository [0] at commit ec55a08dc0244ce570c4fc7cade330c60798952f,
This is a straight import of the OpenSSL/CRYPTOGAMS Poly1305 implementation for
MIPS authored by Andy Polyakov, a prior 64-bit only version of which has been
contributed by him to the OpenSSL project. The file 'poly1305-mips.pl' is taken
straight from this upstream GitHub repository [0] at commit
d
In order to use 128-bit integer arithmetic in C code, the architecture
needs to have declared support for it by setting ARCH_SUPPORTS_INT128,
and it requires a version of the toolchain that supports this at build
time. This is why all existing tests for ARCH_SUPPORTS_INT128 also test
whether __SIZE
From: "Jason A. Donenfeld"
This ports the SUPERCOP implementation for usage in kernel space. In
addition to the usual header, macro, and style changes required for
kernel space, it makes a few small changes to the code:
- The stack alignment is relaxed to 16 bytes.
- Superfluous mov statemen
From: "Jason A. Donenfeld"
This implementation is the fastest available x86_64 implementation, and
unlike Sandy2x, it doesn't requie use of the floating point registers at
all. Instead it makes use of BMI2 and ADX, available on recent
microarchitectures. The implementation was written by Armando
From: "Jason A. Donenfeld"
This comes from Dan Bernstein and Peter Schwabe's public domain NEON
code, and is included here in raw form so that subsequent commits that
fix these up for the kernel can see how it has changed. This code does
have some entirely cosmetic formatting differences, adding
Reimplement the library routines to perform chacha20poly1305 en/decryption
on scatterlists, without [ab]using the [deprecated] blkcipher interface,
which is rather heavyweight and does things we don't really need.
Instead, we use the sg_miter API in a novel and clever way, to iterate
over the scat
> -Original Message-
> From: Pascal Van Leeuwen
> Sent: Thursday, October 17, 2019 7:14 PM
> To: 'Ben Dooks (Codethink)' ; linux-
> ker...@lists.codethink.co.uk
> Cc: Antoine Tenart ; Herbert Xu
> ; David S. Miller ; linux-
> cry...@vger.kernel.org; linux-ker...@vger.kernel.org
> Subject: R
From: Ashish Kalra
SEV INIT command loads the SEV related persistent data from NVS
and initializes the platform context. The firmware validates the
persistent state. If validation fails, the firmware will reset
the persisent state and return an integrity check failure status.
At this point, a su
"ctx" is uninitialized. To avoid undefined behaviors or memory
disclosures, we better initialize it.
Signed-off-by: Kangjie Lu
---
crypto/algif_hash.c | 1 +
1 file changed, 1 insertion(+)
diff --git a/crypto/algif_hash.c b/crypto/algif_hash.c
index 178f4cd75ef1..129a124e5056 100644
--- a/crypt
On Wed, 2019-10-02 at 21:47 +0800, Neal Liu wrote:
> Dear Rob,
>
> Just a gentle ping.
>
> Neal
>
> On Wed, 2019-09-18 at 09:44 +0800, Neal Liu wrote:
> > On Tue, 2019-07-23 at 22:35 +0800, Rob Herring wrote:
> > > On Mon, Jul 22, 2019 at 8:21 PM Neal Liu wrote:
> > > >
> > >
> > > Please don'
On Fri, Oct 18, 2019 at 12:04:56AM -0500, Kangjie Lu wrote:
> "ctx" is uninitialized. To avoid undefined behaviors or memory
> disclosures, we better initialize it.
>
> Signed-off-by: Kangjie Lu
Please be more specific about what undefined behaviours you're
referring to.
Cheers,
--
Email: Herb
76 matches
Mail list logo
