On Thu, Jun 27, 2019 at 3:50 AM Horia Geanta wrote:
>
> On 6/17/2019 7:04 PM, Andrey Smirnov wrote:
> > Exactly the same code to figure out DMA mask is repeated twice in the
> > driver code. To avoid repetition, move that logic into a standalone
> > subroutine in intern.h. While at it re-shuffle t
Add self-tests for the lzo-rle algorithm.
Signed-off-by: Hannah Pan
---
crypto/testmgr.c | 10 ++
crypto/testmgr.h | 80
2 files changed, 90 insertions(+)
diff --git a/crypto/testmgr.c b/crypto/testmgr.c
index 658a7eeebab2..c8a2fd96384d 10064
From: Eric Biggers
Michal Suchanek reported [1] that running the pcrypt_aead01 test from
LTP [2] in a loop and holding Ctrl-C causes a NULL dereference of
alg->cra_users.next in crypto_remove_spawns(), via crypto_del_alg().
The test repeatedly uses CRYPTO_MSG_NEWALG and CRYPTO_MSG_DELALG.
The cr
On Mon, Jul 01, 2019 at 03:31:54PM +0200, Michal Suchánek wrote:
> On Tue, 25 Jun 2019 09:40:54 -0700
> Eric Biggers wrote:
>
> > Hi Michal,
> >
> > On Tue, Jun 25, 2019 at 09:16:24AM +0200, Michal Suchanek wrote:
> > > Reportedly on Linux 4.12 the LTP testsuite crashes at pcrypt_aead01
> > > i
Hi,
I just noticed two bogus unnumbered (i.e. just designated [PATCH]) patch files
got accidentally
included in my patch submission. Please ignore those.
Sorry about that,
Pascal van Leeuwen
Silicon IP Architect, Multi-Protocol Engines @ Verimatrix
www.insidesecure.com
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-neon.S | 74 +---
1 file changed, 3 insertions(+), 71 deletions(-)
diff --git a/arch/arm64/crypto/aes-neon.S b/arch/arm64/crypto/aes-neon.S
index 29100f692e8a..169e86d8ae36 100644
--- a/arch/arm64/crypto/aes-neon.S
+++ b/arc
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-cipher-core.S | 40 +---
1 file changed, 1 insertion(+), 39 deletions(-)
diff --git a/arch/arm64/crypto/aes-cipher-core.S
b/arch/arm64/crypto/aes-cipher-core.S
index 3a44eada2347..27dac259b359 100644
--- a/arch/arm64/crypto
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-cipher-core.S | 40 +---
1 file changed, 1 insertion(+), 39 deletions(-)
diff --git a/arch/arm/crypto/aes-cipher-core.S
b/arch/arm/crypto/aes-cipher-core.S
index f2d67c095e59..180d8555a09c 100644
--- a/arch/arm/crypto/aes-cip
In preparation of duplicating the sync ctr(aes) functionality to modules
under arch/arm, move the helper function from a inline .h file to the
AES library, which is already depended upon by the drivers that use this
fallback.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-ctr-fallback.h
Align ARM's hw instruction based AES implementation with other versions
that keep the key schedule in native endianness. This will allow us to
merge the various implementations going forward.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-core.S | 20 ++--
arch/arm/cryp
The AES assembler code for x86 isn't actually faster than code
generated by the compiler from aes_generic.c, and considering
the disproportionate maintenance burden of assembler code on
x86, it is better just to drop it entirely. Modern x86 systems
will use AES-NI anyway, and given that the modules
Instead of calling into the table based scalar AES code in situations
where the SIMD unit may not be used, use the generic AES code, which
is more appropriate since it is less likely to be susceptible to
timing attacks.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 2 +-
Switch to the new AES library that also provides an implementation of
the AES key expansion routine. This removes the dependency on the
generic AES cipher, allowing it to be omitted entirely in the future.
While at it, remove some references to the table based arm64 version
of AES and replace them
Switch to the new AES library that also provides an implementation of
the AES key expansion routine. This removes the dependency on the
generic AES cipher, allowing it to be omitted entirely in the future.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/Kconfig | 2 +-
drivers/crypto/padl
The versions of the AES lookup tables that are only used during the last
round are never used outside of the driver, so there is no need to
export their symbols.
Signed-off-by: Ard Biesheuvel
---
crypto/aes_generic.c | 6 ++
include/crypto/aes.h | 2 --
2 files changed, 2 insertions(+), 6 de
There are a few copies of the AES S-boxes floating around, so export
the ones from the AES library so that we can reuse them in other
modules.
Signed-off-by: Ard Biesheuvel
---
include/crypto/aes.h | 3 +++
lib/crypto/aes.c | 6 ++
2 files changed, 9 insertions(+)
diff --git a/include/c
Use the AES library instead of the cipher interface to perform
the single block of AES processing involved in updating the key
of the cmac(aes) hash.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/ccp/Kconfig | 1 +
drivers/crypto/ccp/ccp-crypto-aes-cmac.c | 25 -
Switch to the new AES library that also provides an implementation of
the AES key expansion routine. This removes the dependency on the
generic AES cipher, allowing it to be omitted entirely in the future.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/Kconfig | 2 +-
drivers/crypto/m
The AMCC code for GCM key derivation allocates a AES cipher to
perform a single block encryption. So let's switch to the new
and more lightweight AES library instead.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/Kconfig | 2 +-
drivers/crypto/amcc/crypto4xx_alg.c | 24 +++--
Switch to the new AES library that also provides an implementation of
the AES key expansion routine. This removes the dependency on the
generic AES cipher, allowing it to be omitted entirely in the future.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/Kconfig | 2 +-
arch/arm/crypt
The scalar table based AES routines are not used by other drivers, so
let's keep it that way and unexport the symbols.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-cipher-glue.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/arch/arm/crypto/aes-cipher-glue.c
b/arch/arm/crypto/ae
Replace a couple of occurrences where the "aes-generic" cipher is
instantiated explicitly and only used for encryption of a single block.
Use AES library calls instead.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/chelsio/Kconfig | 1 +
drivers/crypto/chelsio/chcr_algo.c | 46
Switch to the new AES library that also provides an implementation of
the AES key expansion routine. This removes the dependency on the
generic AES cipher, allowing it to be omitted entirely in the future.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 1 +
arch/arm64/cr
Drop aes-generic's version of crypto_aes_expand_key(), and switch to
the key expansion routine provided by the AES library. AES key expansion
is not performance critical, and it is better to have a single version
shared by all AES implementations.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig
This started out as an attempt to provide synchronous SIMD based GCM
on 32-bit ARM, but along the way, I ended up changing and cleaning up
so many things that it is more of a general AES cleanup now rather than
anything else.
Changes since v3:
- fix build warning due to missing array dimensions of
The bluetooth code uses a bare AES cipher for the encryption operations.
Given that it carries out a set_key() operation right before every
encryption operation, this is clearly not a hot path, and so the use of
the cipher interface (which provides the best implementation available
on the system) i
Switch to the new AES library that also provides an implementation of
the AES key expansion routine. This removes the dependency on the
generic AES cipher, allowing it to be omitted entirely in the future.
Signed-off-by: Ard Biesheuvel
---
drivers/crypto/Kconfig | 2 +-
d
Rename some local AES encrypt/decrypt routines so they don't clash with
the names we are about to introduce for the routines exposed by the
generic AES library.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-cipher-glue.c | 8
arch/arm64/crypto/aes-cipher-glue.c | 8
a
Rearrange the aes_algs[] array for legibility.
Signed-off-by: Ard Biesheuvel
---
arch/arm/crypto/aes-ce-glue.c | 116 ++--
1 file changed, 56 insertions(+), 60 deletions(-)
diff --git a/arch/arm/crypto/aes-ce-glue.c b/arch/arm/crypto/aes-ce-glue.c
index 5affb8482379..04ba6690367
Take the existing small footprint and mostly time invariant C code
and turn it into a AES library that can be used for non-performance
critical, casual use of AES, and as a fallback for, e.g., SIMD code
that needs a secondary path that can be taken in contexts where the
SIMD unit is off limits (e.g
AES in CTR mode is used by modes such as GCM and CCM, which are often
used in contexts where only synchronous ciphers are permitted. So
provide a synchronous version of ctr(aes) based on the existing code.
This requires a non-SIMD fallback to deal with invocations occurring
from a context where SIM
The CCM code calls directly into the scalar table based AES cipher for
arm64 from the fallback path, and since this implementation is known to
be non-time invariant, doing so from a time invariant SIMD cipher is a
bit nasty.
So let's switch to the AES library - this makes the code more robust,
and
The fixed time AES code mangles the key schedule so that xoring the
first round key with values at fixed offsets across the Sbox produces
the correct value. This primes the D-cache with the entire Sbox before
any data dependent lookups are done, making it more difficult to infer
key bits from timin
The GHASH code uses the generic AES key expansion routines, and calls
directly into the scalar table based AES cipher for arm64 from the
fallback path, and since this implementation is known to be non-time
invariant, doing so from a time invariant SIMD cipher is a bit nasty.
So let's switch to the
Add a static inline helper modeled after crypto_cbc_encrypt_walk()
that can be reused for SIMD algorithms that need to implement a
non-SIMD fallback for performing CTR encryption.
Signed-off-by: Ard Biesheuvel
---
include/crypto/ctr.h | 50
1 file changed, 50 insertions(+)
GHASH is used by the GCM mode, which is often used in contexts where
only synchronous ciphers are permitted. So provide a synchronous version
of GHASH based on the existing code. This requires a non-SIMD fallback
to deal with invocations occurring from a context where SIMD instructions
may not be u
AES in CTR mode is used by modes such as GCM and CCM, which are often
used in contexts where only synchronous ciphers are permitted. So
provide a synchronous version of ctr(aes) based on the existing code.
This requires a non-SIMD fallback to deal with invocations occurring
from a context where SIM
The AES-NI code contains fallbacks for invocations that occur from a
context where the SIMD unit is unavailable, which really only occurs
when running in softirq context that was entered from a hard IRQ that
was taken while running kernel code that was already using the FPU.
That means performance
On 7/2/19 12:32 PM, Cfir Cohen wrote:
> Avoid leaking GCM tag through timing side channel.
>
> Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
> Cc: # v4.12+
> Signed-off-by: Cfir Cohen
Acked-by: Gary R Hook
> ---
> drivers/crypto/ccp/ccp-ops.c | 3 ++-
> 1 file
On 7/2/19 11:06 AM, Eric Biggers wrote:
> Hi Tom and Gary,
>
> On latest cryptodev tree, I'm seeing the following self-test failure after I
> built a kernel with the AMD CCP driver and crypto self-tests enabled, and
> booted
> it on system with a Ryzen processor ("Threadripper 1950X"):
>
> [
Avoid leaking GCM tag through timing side channel.
Fixes: 36cf515b9bbe ("crypto: ccp - Enable support for AES GCM on v5 CCPs")
Cc: # v4.12+
Signed-off-by: Cfir Cohen
---
drivers/crypto/ccp/ccp-ops.c | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)
diff --git a/drivers/crypto/ccp/ccp-ops
Hi Tom and Gary,
On latest cryptodev tree, I'm seeing the following self-test failure after I
built a kernel with the AMD CCP driver and crypto self-tests enabled, and booted
it on system with a Ryzen processor ("Threadripper 1950X"):
[4.378985] alg: aead: gcm-aes-ccp encryption test failed (
On Tue, Jul 02, 2019 at 03:41:23PM +, Gary R Hook wrote:
> On 7/1/19 7:25 PM, Eric Biggers wrote:
> > On Mon, Jul 01, 2019 at 05:01:32PM -0700, Cfir Cohen wrote:
> >> Avoid leaking GCM tag through timing side channel.
> >>
> >> Signed-off-by: Cfir Cohen
> >> ---
> >> drivers/crypto/ccp/ccp-o
From: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel_cipher.c | 178 +++--
1 file changed, 136 insertions(+), 42 deletions(-)
diff --git a/drivers/crypto/inside-secure/safexcel_cipher.c
b/drivers/crypto/inside-secure/safexcel_cipher.c
index 7977e4c..9ba2c21 10
From: Pascal van Leeuwen
This patch backs out some changes done with commit 082ec2d48467 -
"add support for HMAC updates" as that update just works around the
issue for the basic tests by providing twice the amount of buffering,
but this does not solve the case of much larger data blocks such as
From: Pascal van Leeuwen
This patch fixes corruption issues with the skcipher output IV
witnessed on x86+EIP197-FPGA (devboard). The original fix, commit
57660b11d5ad ("crypto: inside-secure - implement IV retrieval"),
attempted to write out the result IV through the context record.
However, this
This patch set fixes all remaining issues with the cryptomgr extra tests
when run on a Marvell A7K or A8K device (i.e Macchiatobin), resulting in
a clean boot with the extra tests enabled.
Pascal van Leeuwen (9):
crypto: inside-secure - keep ivsize for DES ECB modes at 0
crypto: inside-secure
From: Pascal van Leeuwen
The driver was loading the initial digest for hash operations into
the hardware explicitly, but this is not needed as the hardware can
handle that by itself, which is more efficient and avoids any context
record coherence issues.
Signed-off-by: Pascal van Leeuwen
---
d
From: Pascal van Leeuwen
Driver was printing an error message for certain input error cases that
should just return -EINVAL, which caused the related testmgr extra tests
to flood the kernel message log. Ensured those cases remain silent while
making some other device-specific errors a bit more ve
From: Pascal van Leeuwen
This patch fixes a buffer overflow error returning -EINVAL for AEAD
decrypt operations by NOT appending the (already verified) ICV to
the output packet (which is not expected by the API anyway).
With this fix, all testmgr AEAD (extra) tests now pass.
Signed-off-by: Pasca
From: Pascal van Leeuwen
This patch adds support for the specific corner case of performing HMAC
on an empty string (i.e. payload length is zero). This solves the last
failing cryptomgr extratests for HMAC.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel_hash.c | 47
From: Pascal van Leeuwen
This patch fixes an issue with hash and HMAC operations that perform
"large" intermediate updates (i.e. combined size > 2 hash blocks) by
actually making use of the hardware's hash continue capabilities.
The original implementation would cache these updates in a buffer th
From: Pascal van Leeuwen
Fixed issues with the skcipher and AEAD scatter/gather list to engine
descriptor conversion code which caused either too much or too little
buffer space to be provided to the hardware. This caused errors with the
testmgr extra tests, either kernel panics (on x86-EIP197-FP
From: Pascal van Leeuwen
Fixed issues with the skcipher and AEAD scatter/gather list to engine
descriptor conversion code which caused either too much or too little
buffer space to be provided to the hardware. This caused errors with the
testmgr extra tests, either kernel panics (on x86-EIP197-FP
From: Pascal van Leeuwen
The driver incorrectly advertised the IV size for DES and 3DES ECB
mode as being the DES blocksize of 8. This is incorrect as ECB mode
does not need any IV.
Signed-off-by: Pascal van Leeuwen
---
drivers/crypto/inside-secure/safexcel_cipher.c | 2 --
1 file changed, 2 d
On 7/1/19 7:25 PM, Eric Biggers wrote:
> On Mon, Jul 01, 2019 at 05:01:32PM -0700, Cfir Cohen wrote:
>> Avoid leaking GCM tag through timing side channel.
>>
>> Signed-off-by: Cfir Cohen
>> ---
>> drivers/crypto/ccp/ccp-ops.c | 3 ++-
>> 1 file changed, 2 insertions(+), 1 deletion(-)
>>
>> diff
When ccree driver runs it checks the state of the Trusted Execution
Environment CryptoCell driver before proceeding. We did not account
for cases where the TEE side is not ready or not available at all.
Fix it by only considering TEE error state after sync with the TEE
side driver.
Signed-off-by:
Register a FIPS test failure notifier and use it to notify
TEE side of FIPS test failures on our side prior to panic.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/cc_fips.c | 23 +++
1 file changed, 23 insertions(+)
diff --git a/drivers/crypto/ccree/cc_fips.c b/d
Crypto test failures in FIPS mode cause an immediate panic, but
on some system the cryptographic boundary extends beyond just
the Linux controlled domain.
Add a simple atomic notification chain to allow interested parties
to register to receive notification prior to us kicking the bucket.
Signed-
ccree had a mechanism for IV generation which was not compatible
with the Linux seqiv or echainiv iv generator and was never used
in any of the upstream versions so drop all the code implementing it.
Signed-off-by: Gilad Ben-Yossef
---
drivers/crypto/ccree/Makefile | 2 +-
drivers/cryp
Clean up unused ivgen support code and add support for notifiying
Trusted Execution Enviornment of FIPS tests failures in FIPS mode.
Gilad Ben-Yossef (4):
crypto: ccree: drop legacy ivgen support
crypto: ccree: account for TEE not ready to report
crypto: fips: add FIPS test failure notificat
On Fri, Jun 28, 2019 at 11:35:21AM +0200, Ard Biesheuvel wrote:
> Signed-off-by: Ard Biesheuvel
> ---
> drivers/crypto/sunxi-ss/sun4i-ss-cipher.c | 26 +---
> drivers/crypto/sunxi-ss/sun4i-ss.h| 2 +-
> 2 files changed, 7 insertions(+), 21 deletions(-)
>
Acked-by: Coren
Hi Herbert,
Le 24/06/2019 à 09:21, Christophe Leroy a écrit :
This series is the last set of fixes for the Talitos driver.
Do you plan to apply this series, or are you expecting anythink from
myself ?
Thanks
Christophe
We now get a fully clean boot on both SEC1 (SEC1.2 on mpc885) and
SEC
cryptd_skcipher_free() fails to free the struct skcipher_instance
allocated in cryptd_create_skcipher(), leading to a memory leak. This
is detected by kmemleak on bootup on ARM64 platforms:
unreferenced object 0x80003377b180 (size 1024):
comm "cryptomgr_probe", pid 822, jiffies 4294894830
64 matches
Mail list logo
