On Wed, 2019-06-12 at 18:19 +0200, Ard Biesheuvel wrote:
> This is a follow-up to, and supersedes [0], which moved some WEP code from
> the cipher to the skcipher interface, in order to reduce the use of the bare
> cipher interface in non-crypto subsystem code.
>
> Since using the skcipher interfa
On Wed, Jun 12, 2019 at 06:19:52PM +0200, Ard Biesheuvel wrote:
> This is a follow-up to, and supersedes [0], which moved some WEP code from
> the cipher to the skcipher interface, in order to reduce the use of the bare
> cipher interface in non-crypto subsystem code.
>
> Since using the skcipher
On Wed, 12 Jun 2019 at 16:00, Ard Biesheuvel wrote:
>
> On Wed, 12 Jun 2019 at 15:58, Herbert Xu wrote:
> >
> > On Wed, Jun 12, 2019 at 02:48:18PM +0200, Ard Biesheuvel wrote:
> > >
> > > All the patches leading up to that are cleanups for the AES code, to
> > > reduce
> > > the dependency on th
On Wed, Jun 12, 2019 at 6:53 AM Leonard Crestez wrote:
>
> On 07.06.2019 23:03, Andrey Smirnov wrote:
>
> > There are no clocks that the CAAM driver needs to initialise on the
> > i.MX8.
>
> The clk handling inside CAAM is very convoluted and this patch doesn't
> help. All the driver actually does
The MPPE code uses the sync skcipher to invoke the ecb(arc4) skcipher,
of which only a single generic C code implementation exists. This means
that going through all the trouble of using scatterlists etc buys us
very little, and we're better off just invoking the arc4 library directly.
Note that t
The CIFS code uses the sync skcipher API to invoke the ecb(arc4) skcipher,
of which only a single generic C code implementation exists. This means
that going through all the trouble of using scatterlists etc buys us
very little, and we're better off just invoking the arc4 library directly.
This al
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Signed-off-by: Ard Biesheuvel
---
net/wireless/Kconfig | 1 +
net/wireless/lib80211
The WEP code in the mac80211 subsystem currently uses the crypto
API to access the arc4 (RC4) cipher, which is overly complicated,
and doesn't really have an upside in this particular case, since
ciphers are always synchronous and therefore always implemented in
software. Given that we have no acce
The crypto API abstraction is not very useful for invoking ciphers
directly, especially in the case of arc4, which only has a generic
implementation in C. So let's invoke the library code directly.
Signed-off-by: Ard Biesheuvel
---
net/wireless/Kconfig | 1 +
net/wireless/lib80211_
There are no remaining users of the cipher implementation, and there
are no meaningful ways in which the arc4 cipher can be combined with
templates other than ECB (and the way we do provide that combination
is highly dubious to begin with).
So let's drop the arc4 cipher altogether, and only keep t
Refactor the core rc4 handling so we can move most users to a library
interface, permitting us to drop the cipher interface entirely in a
future patch. This is part of an effort to simplify the crypto API
and improve its robustness against incorrect use.
Signed-off-by: Ard Biesheuvel
---
MAINTAI
This is a follow-up to, and supersedes [0], which moved some WEP code from
the cipher to the skcipher interface, in order to reduce the use of the bare
cipher interface in non-crypto subsystem code.
Since using the skcipher interface to invoke the generic C implementation of
an algorithm that is k
On Wed, 12 Jun 2019 at 17:42, Eric Biggers wrote:
>
> On Wed, Jun 12, 2019 at 01:09:35AM +0200, Ard Biesheuvel wrote:
> > The crypto API abstraction is not very useful for invoking ciphers
> > directly, especially in the case of arc4, which only has a generic
> > implementation in C. So let's invo
On Wed, Jun 12, 2019 at 01:09:35AM +0200, Ard Biesheuvel wrote:
> The crypto API abstraction is not very useful for invoking ciphers
> directly, especially in the case of arc4, which only has a generic
> implementation in C. So let's invoke the library code directly.
>
> Signed-off-by: Ard Biesheu
On Wed, 12 Jun 2019 at 17:33, Eric Biggers wrote:
>
> On Tue, Jun 11, 2019 at 10:39:39AM -0700, Eric Biggers wrote:
> > > -
> > > static struct skcipher_alg arc4_skcipher = {
> >
> > Similarly this could be renamed from arc4_skcipher to arc4_alg, now that the
> > skcipher algorithm doesn't need t
On Tue, Jun 11, 2019 at 10:39:39AM -0700, Eric Biggers wrote:
> > -
> > static struct skcipher_alg arc4_skcipher = {
>
> Similarly this could be renamed from arc4_skcipher to arc4_alg, now that the
> skcipher algorithm doesn't need to be distinguished from the cipher algorithm.
>
> > .base.c
On Wed, 12 Jun 2019 at 14:48, Ard Biesheuvel wrote:
>
> Rename some local AES encrypt/decrypt routines so they don't clash with
> the names we are about to introduce for the routines exposes by the
> generic AES library.
>
> Signed-off-by: Ard Biesheuvel
I need to respin this patch - the subject
On Wed, Jun 12, 2019 at 03:33:02PM +0200, David Hildenbrand wrote:
> s390x crypto is one of the rare modules that returns -EOPNOTSUPP instead of
> -ENODEV in case HW support is not available.
>
> Convert to -ENODEV, so e.g., systemd's systemd-modules-load.service
> ignores this error properly.
>
The wusb code takes a very peculiar approach at implementing CBC-MAC,
by using plain CBC into a scratch buffer, and taking the output IV
as the MAC.
We can clean up this code substantially by switching to the cbcmac
shash, as exposed by the CCM template. To ensure that the module is
loaded on dema
On 6/12/2019 8:52 AM, Christophe Leroy wrote:
>
>
> Le 11/06/2019 à 18:30, Horia Geanta a écrit :
>> On 6/11/2019 6:40 PM, Christophe Leroy wrote:
>>>
>>>
>>> Le 11/06/2019 à 17:37, Horia Geanta a écrit :
On 6/11/2019 5:39 PM, Christophe Leroy wrote:
> This series is the last set of fixe
On Wed, 12 Jun 2019 at 15:58, Herbert Xu wrote:
>
> On Wed, Jun 12, 2019 at 02:48:18PM +0200, Ard Biesheuvel wrote:
> >
> > All the patches leading up to that are cleanups for the AES code, to reduce
> > the dependency on the generic table based AES code, or in some cases,
> > hardcoded
> > depen
On Wed, Jun 12, 2019 at 09:26:02PM +0800, Shawn Guo wrote:
>
> Yes, it happens from time to time depending on maintainer's style. I'm
> fine with the DT changes going through other subsystem tree, if the
> subsystem maintainer wants to and is willing to take the risk of merge
> conflict between his
On Wed, Jun 12, 2019 at 02:48:18PM +0200, Ard Biesheuvel wrote:
>
> All the patches leading up to that are cleanups for the AES code, to reduce
> the dependency on the generic table based AES code, or in some cases,
> hardcoded
> dependencies on the scalar arm64 asm code which suffers from the sam
On 07.06.2019 23:03, Andrey Smirnov wrote:
> There are no clocks that the CAAM driver needs to initialise on the
> i.MX8.
The clk handling inside CAAM is very convoluted and this patch doesn't
help. All the driver actually does is "enable all required clocks", this
shouldn't be complicated.
I
On Wed, 12 Jun 2019 15:33:02 +0200
David Hildenbrand wrote:
> s390x crypto is one of the rare modules that returns -EOPNOTSUPP instead of
> -ENODEV in case HW support is not available.
>
> Convert to -ENODEV, so e.g., systemd's systemd-modules-load.service
> ignores this error properly.
>
> v2
On 6/12/2019 8:49 AM, Christophe Leroy wrote:
> Below commit came with a typo in the CONFIG_ symbol, leading
> to a permanently reduced max key size regarless of the driver
> capabilities.
>
> Reported-by: Horia Geantă
> Fixes: b8fbdc2bc4e7 ("crypto: talitos - reduce max key size for SEC1")
> Sig
Let's use the error value that is typically used if HW support is not
available when trying to load a module - this is also what systemd's
systemd-modules-load.service expects.
Reviewed-by: Cornelia Huck
Reviewed-by: Harald Freudenberger
Signed-off-by: David Hildenbrand
---
arch/s390/crypto/sh
Let's use the error value that is typically used if HW support is not
available when trying to load a module - this is also what systemd's
systemd-modules-load.service expects.
Reviewed-by: Cornelia Huck
Reviewed-by: Harald Freudenberger
Signed-off-by: David Hildenbrand
---
arch/s390/crypto/pr
s390x crypto is one of the rare modules that returns -EOPNOTSUPP instead of
-ENODEV in case HW support is not available.
Convert to -ENODEV, so e.g., systemd's systemd-modules-load.service
ignores this error properly.
v2 -> v3:
- "s390/pkey: Use -ENODEV instead of -EOPNOTSUPP"
-- Also convert pke
Let's use the error value that is typically used if HW support is not
available when trying to load a module - this is also what systemd's
systemd-modules-load.service expects.
Reviewed-by: Cornelia Huck
Reviewed-by: Harald Freudenberger
Signed-off-by: David Hildenbrand
---
arch/s390/crypto/gh
systemd-modules-load.service automatically tries to load the pkey module
on systems that have MSA.
Pkey also requires the MSA3 facility and a bunch of subfunctions.
Failing with -EOPNOTSUPP makes "systemd-modules-load.service" fail on
any system that does not have all needed subfunctions. For exam
On Wed, Jun 12, 2019 at 01:15:46PM +, Horia Geanta wrote:
> On 6/12/2019 4:06 PM, Shawn Guo wrote:
> > On Wed, Jun 12, 2019 at 11:45:18AM +, Horia Geanta wrote:
> >> On 6/12/2019 1:40 PM, Shawn Guo wrote:
> >>> On Thu, Jun 06, 2019 at 11:02:55AM +0300, Horia Geantă wrote:
> From: Iulia
On 6/12/2019 4:06 PM, Shawn Guo wrote:
> On Wed, Jun 12, 2019 at 11:45:18AM +, Horia Geanta wrote:
>> On 6/12/2019 1:40 PM, Shawn Guo wrote:
>>> On Thu, Jun 06, 2019 at 11:02:55AM +0300, Horia Geantă wrote:
From: Iuliana Prodan
Add crypto node in device tree for CAAM support.
>>
On Wed, Jun 12, 2019 at 11:45:18AM +, Horia Geanta wrote:
> On 6/12/2019 1:40 PM, Shawn Guo wrote:
> > On Thu, Jun 06, 2019 at 11:02:55AM +0300, Horia Geantă wrote:
> >> From: Iuliana Prodan
> >>
> >> Add crypto node in device tree for CAAM support.
> >>
> >> Noteworthy is that on 7ulp the int
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
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
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
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
Rename some local AES encrypt/decrypt routines so they don't clash with
the names we are about to introduce for the routines exposes 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
c
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
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.
This is posted as an RFC since using the mostly-fixed-time C code as
lib
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
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 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
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 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
Drop aes-generic's version of crypto_aes_expand_key(), and switch to
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
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.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 1 +
arch/arm64/cr
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| 2 +-
arch/arm64/crypto/
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
Turn 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
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
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
On 6/12/2019 1:40 PM, Shawn Guo wrote:
> On Thu, Jun 06, 2019 at 11:02:55AM +0300, Horia Geantă wrote:
>> From: Iuliana Prodan
>>
>> Add crypto node in device tree for CAAM support.
>>
>> Noteworthy is that on 7ulp the interrupt line is shared
>> between the two job rings.
>>
>> Signed-off-by: Iul
On Wed, Jun 12, 2019 at 10:33:56AM +, Horia Geanta wrote:
> On 6/12/2019 12:40 PM, Sascha Hauer wrote:
> > Hi Horia,
> >
> > On Wed, May 15, 2019 at 01:35:16PM +, Horia Geanta wrote:
> >> For talitos, the problem is the lack of IV update.
> >>
> >> For caam, the problem is incorrect IV upd
On 12.06.19 13:07, Harald Freudenberger wrote:
> On 12.06.19 12:41, David Hildenbrand wrote:
>> On 12.06.19 12:39, Harald Freudenberger wrote:
>>> On 12.06.19 12:22, David Hildenbrand wrote:
systemd-modules-load.service automatically tries to load the pkey module
on systems that have MSA.
On 12.06.19 12:41, David Hildenbrand wrote:
> On 12.06.19 12:39, Harald Freudenberger wrote:
>> On 12.06.19 12:22, David Hildenbrand wrote:
>>> systemd-modules-load.service automatically tries to load the pkey module
>>> on systems that have MSA.
>>>
>>> Pkey also requires the MSA3 facility and a b
On 12.06.19 12:39, Harald Freudenberger wrote:
> On 12.06.19 12:22, David Hildenbrand wrote:
>> systemd-modules-load.service automatically tries to load the pkey module
>> on systems that have MSA.
>>
>> Pkey also requires the MSA3 facility and a bunch of subfunctions.
>> Failing with -EOPNOTSUPP m
On Thu, Jun 06, 2019 at 11:02:55AM +0300, Horia Geantă wrote:
> From: Iuliana Prodan
>
> Add crypto node in device tree for CAAM support.
>
> Noteworthy is that on 7ulp the interrupt line is shared
> between the two job rings.
>
> Signed-off-by: Iuliana Prodan
> Signed-off-by: Franck LENORMAND
On 12.06.19 12:22, David Hildenbrand wrote:
> systemd-modules-load.service automatically tries to load the pkey module
> on systems that have MSA.
>
> Pkey also requires the MSA3 facility and a bunch of subfunctions.
> Failing with -EOPNOTSUPP makes "systemd-modules-load.service" fail on
> any syst
On Wed, 12 Jun 2019 12:22:48 +0200
David Hildenbrand wrote:
> Let's use the error value that is typically used if HW support is not
> available when trying to load a module - this is also what systemd's
> systemd-modules-load.service expects.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s
On Wed, 12 Jun 2019 12:22:47 +0200
David Hildenbrand wrote:
> Let's use the error value that is typically used if HW support is not
> available when trying to load a module - this is also what systemd's
> systemd-modules-load.service expects.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s
On 6/12/2019 12:40 PM, Sascha Hauer wrote:
> Hi Horia,
>
> On Wed, May 15, 2019 at 01:35:16PM +, Horia Geanta wrote:
>> For talitos, the problem is the lack of IV update.
>>
>> For caam, the problem is incorrect IV update (output IV is equal to last
>> ciphertext block, which is correect for c
On 12.06.19 12:22, David Hildenbrand wrote:
> Let's use the error value that is typically used if HW support is not
> available when trying to load a module - this is also what systemd's
> systemd-modules-load.service expects.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s390/crypto/ghash_s3
On Wed, 12 Jun 2019 12:22:46 +0200
David Hildenbrand wrote:
> Let's use the error value that is typically used if HW support is not
> available when trying to load a module - this is also what systemd's
> systemd-modules-load.service expects.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s
On 12.06.19 12:22, David Hildenbrand wrote:
> Let's use the error value that is typically used if HW support is not
> available when trying to load a module - this is also what systemd's
> systemd-modules-load.service expects.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s390/crypto/sha1_s39
On 12.06.19 12:22, David Hildenbrand wrote:
> Let's use the error value that is typically used if HW support is not
> available when trying to load a module - this is also what systemd's
> systemd-modules-load.service expects.
>
> Signed-off-by: David Hildenbrand
> ---
> arch/s390/crypto/prng.c |
Let's use the error value that is typically used if HW support is not
available when trying to load a module - this is also what systemd's
systemd-modules-load.service expects.
Signed-off-by: David Hildenbrand
---
arch/s390/crypto/prng.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
s390x crypto is one of the rare modules that returns -EOPNOTSUPP instead of
-ENODEV in case HW support is not available.
Convert to -ENODEV, so e.g., systemd's systemd-modules-load.service
ignores this error properly.
v1 -> v2:
- Include
-- "s390/crypto: ghash: Use -ENODEV instead of -EOPNOTSUPP"
systemd-modules-load.service automatically tries to load the pkey module
on systems that have MSA.
Pkey also requires the MSA3 facility and a bunch of subfunctions.
Failing with -EOPNOTSUPP makes "systemd-modules-load.service" fail on
any system that does not have all needed subfunctions. For exam
Let's use the error value that is typically used if HW support is not
available when trying to load a module - this is also what systemd's
systemd-modules-load.service expects.
Signed-off-by: David Hildenbrand
---
arch/s390/crypto/sha1_s390.c | 2 +-
arch/s390/crypto/sha256_s390.c | 2 +-
arch
Let's use the error value that is typically used if HW support is not
available when trying to load a module - this is also what systemd's
systemd-modules-load.service expects.
Signed-off-by: David Hildenbrand
---
arch/s390/crypto/ghash_s390.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-
Hi Horia,
On Wed, May 15, 2019 at 01:35:16PM +, Horia Geanta wrote:
> For talitos, the problem is the lack of IV update.
>
> For caam, the problem is incorrect IV update (output IV is equal to last
> ciphertext block, which is correect for cbc, but not for ctr mode).
>
> I am working at a fi
75 matches
Mail list logo
