course we really need the crypto API to enable the correct
> implementations automatically, but that's for a later fix.
>
> Cc: Ard Biesheuvel
> Cc: David Howells
> Cc: Herbert Xu
> Signed-off-by: Eric Biggers
> ---
> fs/crypto/Kconfig | 20 ++++
> 1 fil
On Fri, 13 Sept 2024 at 11:32, David Howells wrote:
>
> Herbert Xu wrote:
>
> > Personally I don't think the argument above holds water. With
> > IPsec we had a similar issue of authenticating untrusted peers
> > using public key cryptography. In that case we successfully
> > delegated the task
From: Ard Biesheuvel
The crc32/crc32c implementations using the scalar CRC32 instructions are
accessed via indirect calls, and so they must be annotated with type ids
in order to execute correctly when kCFI is enabled.
Cc: Kees Cook
Cc: Linus Walleij
Signed-off-by: Ard Biesheuvel
---
arch
On Fri, 17 May 2024 at 15:35, James Bottomley
wrote:
>
> On Fri, 2024-05-17 at 09:20 +0200, Ard Biesheuvel wrote:
> > On Fri, 17 May 2024 at 03:59, James Bottomley
> > wrote:
> > >
> > > On Thu, 2024-05-16 at 20:25 -0400, Nícolas F. R. A. Prado wrote:
>
On Fri, 17 May 2024 at 03:59, James Bottomley
wrote:
>
> On Thu, 2024-05-16 at 20:25 -0400, Nícolas F. R. A. Prado wrote:
...
> > KernelCI has identified a new warning and I tracked it down to this
> > commit. It
> > was observed on the following platforms:
> > * mt8183-kukui-jacuzzi-juniper-sku16
On Thu, 14 Mar 2024 at 21:20, Eric Biggers wrote:
>
> On Thu, Mar 14, 2024 at 04:52:47AM -0700, James Prestwood wrote:
> > IWD uses AF_ALG/keyctl for _all_ its crypto, cipher, and checksum needs.
> > Anything that wifi requires as far as crypto goes IWD uses the kernel,
> > except ECC is the only
s, both of which
are superseded by optimized scalar versions at the very least,
Cc: "Theodore Y. Ts'o"
Cc: Jaegeuk Kim
Cc: Eric Biggers
Ard Biesheuvel (2):
fscrypt: relax Kconfig dependencies for crypto API algorithms
fsverity: relax build time dependency on CRY
so that the generic
driver can be omitted from the build if desired.
Signed-off-by: Ard Biesheuvel
---
fs/verity/Kconfig | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/fs/verity/Kconfig b/fs/verity/Kconfig
index 88fb25119899..24d1b54de807 100644
--- a/fs/verity/Kco
defined by
CONFIG_FS_ENCRYPTION_ALGS.
So let's relax these clauses to 'imply', so that the default behavior
is still to pull in those generic algorithms, but in a way that permits
them to be disabled again in Kconfig.
Signed-off-by: Ard Biesheuvel
---
fs/crypto/Kconfig | 23 ++--
1 fi
On Mon, 12 Apr 2021 at 21:51, Chris von Recklinghausen
wrote:
>
> On 4/12/21 3:27 PM, Ard Biesheuvel wrote:
> > On Mon, 12 Apr 2021 at 21:20, Eric Biggers wrote:
> >> On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote:
> >>> On 4/12/21 1:45
On Mon, 12 Apr 2021 at 21:20, Eric Biggers wrote:
>
> On Mon, Apr 12, 2021 at 03:04:58PM -0400, Chris von Recklinghausen wrote:
> > On 4/12/21 1:45 PM, Eric Biggers wrote:
> > > On Mon, Apr 12, 2021 at 10:09:32AM -0400, Chris von Recklinghausen wrote:
> > > > Suspend fails on a system in fips mode
On Tue, 30 Mar 2021 at 11:52, Will Deacon wrote:
>
> On Tue, Mar 02, 2021 at 10:01:10AM +0100, Ard Biesheuvel wrote:
> > The users of the conditional NEON yield macros have all been switched to
> > the simplified cond_yield macro, and so the NEON specific ones can be
> >
On Fri, 9 Apr 2021 at 05:03, Jason A. Donenfeld wrote:
>
> On Fri, Apr 09, 2021 at 10:49:07AM +0800, Hangbin Liu wrote:
> > On Thu, Apr 08, 2021 at 08:44:35PM -0600, Jason A. Donenfeld wrote:
> > > Since it's just a normal module library, you can simply do this in the
> > > module_init function, r
b465d ("crypto: arm64/aes-ctr - improve tail handling")
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-modes.S | 1 +
1 file changed, 1 insertion(+)
diff --git a/arch/arm64/crypto/aes-modes.S b/arch/arm64/crypto/aes-modes.S
index ab6c14ef9f4e..6d1a120c533d 100644
--- a/arch/a
On Thu, 1 Apr 2021 at 15:54, Chris von Recklinghausen
wrote:
>
> On 4/1/21 9:38 AM, Rafael J. Wysocki wrote:
> > On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> >> On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> >>> On Tue, 2021-03-30 at 21:45 +0200
On Thu, 1 Apr 2021 at 15:38, Rafael J. Wysocki wrote:
>
> On Thu, Apr 1, 2021 at 10:47 AM Ard Biesheuvel wrote:
> >
> > On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
> > >
> > > On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> > > >
On Thu, 1 Apr 2021 at 15:34, Rafael J. Wysocki wrote:
>
> On Thu, Apr 1, 2021 at 2:25 PM Chris von Recklinghausen
> wrote:
> >
> > Suspend fails on a system in fips mode because md5 is used for the e820
> > integrity check and is not available. Use crc32 instead.
> >
> > Fixes: 62a03defeabd ("PM
On Tue, 30 Mar 2021 at 21:56, Simo Sorce wrote:
>
> On Tue, 2021-03-30 at 21:45 +0200, Ard Biesheuvel wrote:
> > On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
> > > On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > > > On Tue, Mar 30, 2
On Tue, 30 Mar 2021 at 20:05, Simo Sorce wrote:
>
> On Tue, 2021-03-30 at 16:46 +0200, Rafael J. Wysocki wrote:
> > On Tue, Mar 30, 2021 at 12:14 AM Dexuan Cui wrote:
> > > Hi,
> > > MD5 was marked incompliant with FIPS in 2009:
> > > a3bef3a31a19 ("crypto: testmgr - Skip algs not flagged fips_al
On Fri, 26 Mar 2021 at 03:22, Tianjia Zhang
wrote:
>
> In the process of calculating the hash, use the more accurate type
> 'u32' instead of the original 'unsigned int' to avoid ambiguity.
>
> Signed-off-by: Tianjia Zhang
I don't see the point of this patch. u32 and unsigned int are always
the s
On Tue, 23 Mar 2021 at 09:36, Tianjia Zhang
wrote:
>
> The kernel module signature supports the option to use the SM3
> secure hash (OSCCA GM/T 0004-2012 SM3).
>
> Signed-off-by: Tianjia Zhang
A secure hash is not the same as a signature. Looking at the patch,
the asymmetric algorithm that is us
305_simd_init() takes only the key but not the nonce, so it
should only be passed 16 bytes.
> Fixes: 1c08a104360f ("crypto: poly1305 - add new 32 and 64-bit generic
> versions")
> Signed-off-by: Arnd Bergmann
Reviewed-by: Ard Biesheuvel
> ---
> arch/arm/crypto/pol
On Thu, 18 Mar 2021 at 18:13, Ard Biesheuvel wrote:
>
> On Thu, 18 Mar 2021 at 17:42, Sasha Levin wrote:
> >
> > On Thu, Mar 18, 2021 at 03:15:35PM +0100, Ard Biesheuvel wrote:
> > >On Thu, 18 Mar 2021 at 14:03, Sasha Levin wrote:
> > >> What about an
On Thu, 18 Mar 2021 at 17:42, Sasha Levin wrote:
>
> On Thu, Mar 18, 2021 at 03:15:35PM +0100, Ard Biesheuvel wrote:
> >On Thu, 18 Mar 2021 at 14:03, Sasha Levin wrote:
> >> What about anything older than 5.10? Looks like it's needed there too?
> >>
> >
On Thu, 18 Mar 2021 at 14:03, Sasha Levin wrote:
>
> On Tue, Mar 16, 2021 at 01:35:40PM +0100, Ard Biesheuvel wrote:
> >On Tue, 16 Mar 2021 at 13:28, Thomas Backlund wrote:
> >>
> >>
> >> Den 16.3.2021 kl. 14:15, skrev Thomas Backlund:
> >> >
&
On Tue, 16 Mar 2021 at 13:28, Thomas Backlund wrote:
>
>
> Den 16.3.2021 kl. 14:15, skrev Thomas Backlund:
> >
> > Den 16.3.2021 kl. 12:17, skrev Ard Biesheuvel:
> >> On Tue, 16 Mar 2021 at 10:21, Thomas Backlund wrote:
> >>> Den 16.3.2021 kl. 08:37, sk
On Tue, 16 Mar 2021 at 10:21, Thomas Backlund wrote:
>
> Den 16.3.2021 kl. 08:37, skrev Ard Biesheuvel:
> > Please consider backporting commit
> >
> > 86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
> > crypto: x86/aes-ni-xts - use direct calls to and 4-way stride
>
Please consider backporting commit
86ad60a65f29dd862a11c22bb4b5be28d6c5cef1
crypto: x86/aes-ni-xts - use direct calls to and 4-way stride
to stable. It addresses a rather substantial retpoline-related
performance regression in the AES-NI XTS code, which is a widely used
disk encryption algorithm
troduces rev_l, it has been merged in v5.12-rc
- rev_32 was renamed to rev_l, so both patches were updated to reflect that
- add acks from Nico, Geert and Linus
Cc: Geert Uytterhoeven
Cc: Nicolas Pitre
Cc: Eric Biggers
Cc: Linus Walleij
Ard Biesheuvel (2):
crypto: arm/aes-scalar - switch to
Drop the local definition of a byte swapping macro and use the common
one instead.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Nicolas Pitre
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Linus Walleij
Reviewed-by: Eric Biggers
---
arch/arm/crypto/chacha-scalar-core.S | 43
The scalar AES implementation has some locally defined macros which
reimplement things that are now available in macros defined in
assembler.h. So let's switch to those.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Nicolas Pitre
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Linus Wa
his.
>
> Fixes: 5172d322d34c ("crypto: arm/blake2s - add ARM scalar optimized BLAKE2s")
> Signed-off-by: Eric Biggers
Acked-by: Ard Biesheuvel
> ---
> arch/arm/crypto/blake2s-core.S | 21 +
> 1 file changed, 21 insertions(+)
>
> diff --git a/a
On Wed, 10 Mar 2021 at 08:09, Eric Biggers wrote:
>
> On Sun, Mar 07, 2021 at 05:54:23PM +0100, Ard Biesheuvel wrote:
> > The scalar AES implementation has some locally defined macros which
> > reimplement things that are now available in macros defined in
> > assembl
)
> > | ^
>
> ---8<---
> This patch fixes missing prototype warnings in crypto/aegis128-neon.c.
>
> Fixes: a4397635afea ("crypto: aegis128 - provide a SIMD...")
> Reported-by: kernel test robot
> Signed-off-by: Herbert Xu
tches were updated to reflect that
- add acks from Nico, Geert and Linux
Cc: Geert Uytterhoeven
Cc: Nicolas Pitre
Cc: Eric Biggers
Cc: Linus Walleij
Ard Biesheuvel (2):
crypto: arm/aes-scalar - switch to common rev_32/mov_l macros
crypto: arm/chacha-scalar - switch to common rev_32 macro
arch/
The scalar AES implementation has some locally defined macros which
reimplement things that are now available in macros defined in
assembler.h. So let's switch to those.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Nicolas Pitre
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Linus Wa
Drop the local definition of a byte swapping macro and use the common
one instead.
Signed-off-by: Ard Biesheuvel
Reviewed-by: Nicolas Pitre
Reviewed-by: Geert Uytterhoeven
Reviewed-by: Linus Walleij
---
arch/arm/crypto/chacha-scalar-core.S | 43 ++--
1 file changed, 13
Please consider applying the following upstream patch to stable trees
v5.4 and up
commit 660d2062190db131d2feaf19914e90f868fe285c
Author: Ard Biesheuvel
Date: Wed Jan 13 10:11:35 2021 +0100
crypto - shash: reduce minimum alignment of shash_desc structure
On architectures such as arm64, it
://lore.kernel.org/linux-crypto/de949705bc59e...@google.com/
Reported-by: syzbot+12cf5fbfdeba210a8...@syzkaller.appspotmail.com
Reviewed-by: Eric Biggers
Signed-off-by: Ard Biesheuvel
---
v3: missed crypto_free_shash() in v2
add Eric's Rb
v2: update kerneldoc comments of calle
Calls into the skcipher API can only occur from contexts where the SIMD
unit is available, so there is no need for the SIMD helper.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig| 2 -
arch/arm64/crypto/aes-glue.c | 102 +++-
2 files changed, 13 insertions
Calls into the skcipher API can only occur from contexts where the SIMD
unit is available, so there is no need for the SIMD helper.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/Kconfig | 1 -
arch/arm64/crypto/aes-neonbs-glue.c | 122 ++--
2 files changed, 9
In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
AEAD encrypt and decrypt routines from outside of task or softirq context.
Signed-off-by: Ard Biesheuvel
---
crypto/aead.c | 10 ++
1 file
fallback path. Let's remove it.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-ce-ccm-glue.c | 151
1 file changed, 30 insertions(+), 121 deletions(-)
diff --git a/arch/arm64/crypto/aes-ce-ccm-glue.c
b/arch/arm64/crypto/aes-ce-ccm-glue.c
index f6d19b0
Now that kernel mode SIMD is guaranteed to be available when executing
in task or softirq context, we no longer need scalar fallbacks to use
when the NEON is unavailable. So get rid of them.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/ghash-ce-glue.c | 209 +---
1 file
The users of the conditional NEON yield macros have all been switched to
the simplified cond_yield macro, and so the NEON specific ones can be
removed.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 70
1 file changed, 70 deletions(-)
diff --git a
In order to ensure that kernel mode SIMD routines will not need a scalar
fallback if they run with softirqs disabled, disallow any use of the
skcipher encrypt and decrypt routines from outside of task or softirq
context.
Signed-off-by: Ard Biesheuvel
---
crypto/skcipher.c | 10 ++
1
his
allows the macro implementation to paste the xN reference after a w to
obtain the correct register name.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 8
1 file changed, 8 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h
b/arch/arm64/include/asm/assembler.
cheap, we can relax this
restriction, by increasing the granularity of kernel mode NEON code, and
always disabling softirq processing while the NEON is being used in task
context.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-modes.S | 2 +-
arch/arm64/crypto/sha1-ce-core.S | 2
ill Deacon
Cc: Catalin Marinas
Cc: Thomas Gleixner
Cc: Peter Zijlstra
Cc: Sebastian Andrzej Siewior
Cc: Ingo Molnar
Cc: Andy Lutomirski
Ard Biesheuvel (9):
arm64: assembler: remove conditional NEON yield macros
arm64: assembler: introduce wxN aliases for wN registers
arm64: fpsimd: run k
://lore.kernel.org/linux-crypto/de949705bc59e...@google.com/
Reported-by: syzbot+12cf5fbfdeba210a8...@syzkaller.appspotmail.com
Signed-off-by: Ard Biesheuvel
---
v2: update kerneldoc comments of callers to crypto_destroy_tfm() that NULL or
error pointers are ignored.
crypto/api.c
://lore.kernel.org/linux-crypto/de949705bc59e...@google.com/
Reported-by: syzbot+12cf5fbfdeba210a8...@syzkaller.appspotmail.com
Signed-off-by: Ard Biesheuvel
---
crypto/api.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/crypto/api.c b/crypto/api.c
index ed08cbd5b9d3
gave this series a spin with CONFIG_CRYPTO_MANAGER_EXTRA_TESTS=y,
and all the tests still pass.
Tested-by: Ard Biesheuvel
Acked-by: Ard Biesheuvel
> arch/x86/crypto/Makefile | 2 -
> arch/x86/crypto/aesni-intel_avx-x86_64.S | 28 +
> arch/x86/cr
On Tue, 16 Feb 2021 at 11:10, Peter Zijlstra wrote:
>
> On Fri, Dec 18, 2020 at 06:01:01PM +0100, Ard Biesheuvel wrote:
> > [ TL;DR for the non-ARM folks on CC: disabling softirq processing when using
> > SIMD in kernel mode could reduce complexity and improve perfor
On Wed, 20 Jan 2021 at 16:44, Dave Martin wrote:
>
> On Tue, Jan 19, 2021 at 05:29:05PM +0100, Ard Biesheuvel wrote:
> > On Tue, 19 Jan 2021 at 17:01, Dave Martin wrote:
> > >
> > > On Fri, Dec 18, 2020 at 06:01:05PM +0100, Ard Biesheuvel wrote:
> > > &g
On Wed, 10 Feb 2021 at 08:16, Herbert Xu wrote:
>
> This patch fixes the byte order markings in serpent.
>
> Signed-off-by: Herbert Xu
Tested-by: Ard Biesheuvel # arm64 big-endian
>
> diff --git a/crypto/serpent_generic.c b/crypto/serpent_generic.c
> index 236c87547a17
On Mon, 8 Feb 2021 at 07:37, Vitaly Chikunov wrote:
>
> Herbert,
>
> On Fri, Jan 29, 2021 at 02:00:04PM +1100, Herbert Xu wrote:
> > On Thu, Jan 28, 2021 at 09:49:41PM -0500, Stefan Berger wrote:
> > >
> > > In my patch series I initially had registered the akciphers under the
> > > names
> > > e
On Sun, 7 Feb 2021 at 03:47, liulongfang wrote:
>
> On 2021/2/5 19:44, Herbert Xu write:
> > On Fri, Feb 05, 2021 at 06:10:57PM +0800, Longfang Liu wrote:
> >> If this configuration item is not turned on,
> >> the allocation of crypto_tfm will fail when
> >> the shash algorithm calculates the hash
On Thu, 4 Feb 2021 at 03:44, Herbert Xu wrote:
>
> On Wed, Feb 03, 2021 at 09:31:31PM +, Will Deacon wrote:
> >
> > Applied first patch only to arm64 (for-next/crypto), thanks!
> >
> > [1/9] arm64: assembler: add cond_yield macro
> > https://git.kernel.org/arm64/c/d13c613f136c
> >
> > Th
the consequences.
This reverts commit 6caf7adc5e458f77f550b6c6ca8effa152d61b4a.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha512-ce-core.S | 29 +++
arch/arm64/crypto/sha512-ce-glue.c | 53 ++--
2 files changed, 34 insertions(+), 48 deletions(-)
diff --git a
point of view.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crct10dif-ce-core.S | 43 +---
arch/arm64/crypto/crct10dif-ce-glue.c | 30 +++---
2 files changed, 35 insertions(+), 38 deletions(-)
diff --git a/arch/arm64/crypto/crct10dif-ce-core.S
b/arch/arm64/crypto
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 21 +---
arch/arm64/crypto/aes-modes.S | 52 +++-
2 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index e7f116d833b9..17e735931a0c
The users of the conditional NEON yield macros have all been switched to
the simplified cond_yield macro, and so the NEON specific ones can be
removed.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 70
1 file changed, 70 deletions(-)
diff --git a
There is no need for elaborate yield handling in the bit-sliced NEON
implementation of AES, given that skciphers are naturally bounded by the
size of the chunks returned by the skcipher_walk API. So remove the
yield calls from the asm code.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto
the consequences.
This reverts commit 7edc86cb1c18b4c274672232117586ea2bef1d9a.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha3-ce-core.S | 81
arch/arm64/crypto/sha3-ce-glue.c | 14 ++--
2 files changed, 39 insertions(+), 56 deletions(-)
diff --git a/arch/arm64
the consequences.
This reverts commit d82f37ab5e2426287013eba38b1212e8b71e5be3.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha2-ce-core.S | 38 +++-
arch/arm64/crypto/sha2-ce-glue.c | 22 ++--
2 files changed, 25 insertions(+), 35 deletions(-)
diff --git a/arch
, which would make chunking the input in order to perform the
cond_resched() check from C code disproportionately costly.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h
b
the consequences.
This reverts commit 7df8d164753e6e6f229b72767595072bc6a71f48.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha1-ce-core.S | 47 +++-
arch/arm64/crypto/sha1-ce-glue.c | 22 -
2 files changed, 29 insertions(+), 40 deletions(-)
diff --git a/arch
it applies cleanly to the arm64
tree)
Will: if you stick #1 on a separate branch, please base it on v5.11-rc1
Changes since v1:
- use sub+cbz instead of cmp+b.eq to avoid clobbering the flags in cond_yield
(patch #1)
Cc: Dave Martin
Cc: Eric Biggers
Ard Biesheuvel (9):
arm64: assembler
On Wed, 3 Feb 2021 at 12:19, Herbert Xu wrote:
>
> On Wed, Feb 03, 2021 at 10:37:10AM +0100, Ard Biesheuvel wrote:
> >
> > One thing that became apparent to me while looking into this stuff is
> > that the skcipher encrypt/decrypt API ignores alignmasks altogether,
>
On Tue, 2 Feb 2021 at 23:20, Eric Biggers wrote:
>
> On Mon, Feb 01, 2021 at 07:02:28PM +0100, Ard Biesheuvel wrote:
> > Some generic implementations of vintage ciphers rely on alignmasks to
> > ensure that the input is presented with the right alignment. Given that
&
ctive architecture, avoiding the need for double buffering.
Signed-off-by: Ard Biesheuvel
---
crypto/twofish_generic.c | 11 +++
1 file changed, 3 insertions(+), 8 deletions(-)
diff --git a/crypto/twofish_generic.c b/crypto/twofish_generic.c
index 4f7c033224f9..86b2f067a416 100644
The fcrypt implementation uses memcpy() to access the input and output
buffers so there is no need to set an alignmask.
Signed-off-by: Ard Biesheuvel
---
crypto/fcrypt.c | 1 -
1 file changed, 1 deletion(-)
diff --git a/crypto/fcrypt.c b/crypto/fcrypt.c
index 58f935315cf8..c36ea0c8be98 100644
ctive architecture, avoiding the need for double buffering.
Signed-off-by: Ard Biesheuvel
---
crypto/cast5_generic.c | 23
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/crypto/cast5_generic.c b/crypto/cast5_generic.c
index 4095085d4e51..0257c14cefc2 100644
ctive architecture, avoiding the need for double buffering.
Signed-off-by: Ard Biesheuvel
---
crypto/cast6_generic.c | 39 +---
1 file changed, 17 insertions(+), 22 deletions(-)
diff --git a/crypto/cast6_generic.c b/crypto/cast6_generic.c
index c77ff6c8a2b2..75346380aa0b 100644
each respective architecture, avoiding the need for double buffering.
Signed-off-by: Ard Biesheuvel
---
crypto/camellia_generic.c | 45 +++-
1 file changed, 16 insertions(+), 29 deletions(-)
diff --git a/crypto/camellia_generic.c b/crypto/camellia_generic.c
index 0b9f409f7370..fd1a88a
ctive architecture, avoiding the need for double buffering.
Signed-off-by: Ard Biesheuvel
---
crypto/serpent_generic.c | 44
1 file changed, 17 insertions(+), 27 deletions(-)
diff --git a/crypto/serpent_generic.c b/crypto/serpent_generic.c
index a932e0b2964f..236c87547a17 1
each respective architecture, avoiding the need for double buffering.
Signed-off-by: Ard Biesheuvel
---
crypto/blowfish_generic.c | 23
1 file changed, 9 insertions(+), 14 deletions(-)
diff --git a/crypto/blowfish_generic.c b/crypto/blowfish_generic.c
index c3c2041fe0c5..003b52c
likely to care anymore today, so let's get rid
of it.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 3 +-
crypto/serpent_generic.c | 82 ++--
crypto/tcrypt.c | 6 +-
crypto/testmgr.c | 6 --
crypto/testmgr.h | 79 -
is pointless. On architectures where this does matter,
setting the cra_alignmask does not actually solve the problem.
So let's get rid of the cra_alignmask, and use unaligned accessors
instead, where appropriate.
Cc:
Signed-off-by: Ard Biesheuvel
---
crypto/michael_mic.c
other than x86.
Ard Biesheuvel (9):
crypto: michael_mic - fix broken misalignment handling
crypto: serpent - get rid of obsolete tnepres variant
crypto: serpent - use unaligned accessors instead of alignmask
crypto: blowfish - use unaligned accessors instead of alignmask
crypto: came
On Thu, 28 Jan 2021 at 21:25, Will Deacon wrote:
>
> On Thu, Jan 28, 2021 at 08:24:01PM +, Will Deacon wrote:
> > On Thu, Jan 28, 2021 at 02:06:17PM +0100, Ard Biesheuvel wrote:
> > > Add a macro cond_yield that branches to a specified label when called if
> > >
point of view.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/crct10dif-ce-core.S | 43 +---
arch/arm64/crypto/crct10dif-ce-glue.c | 30 +++---
2 files changed, 35 insertions(+), 38 deletions(-)
diff --git a/arch/arm64/crypto/crct10dif-ce-core.S
b/arch/arm64/crypto
The users of the conditional NEON yield macros have all been switched to
the simplified cond_yield macro, and so the NEON specific ones can be
removed.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 70
1 file changed, 70 deletions(-)
diff --git a
There is no need for elaborate yield handling in the bit-sliced NEON
implementation of AES, given that skciphers are naturally bounded by the
size of the chunks returned by the skcipher_walk API. So remove the
yield calls from the asm code.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/aes-glue.c | 21 +---
arch/arm64/crypto/aes-modes.S | 52 +++-
2 files changed, 33 insertions(+), 40 deletions(-)
diff --git a/arch/arm64/crypto/aes-glue.c b/arch/arm64/crypto/aes-glue.c
index e7f116d833b9..17e735931a0c
the consequences.
This reverts commit d82f37ab5e2426287013eba38b1212e8b71e5be3.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha2-ce-core.S | 38 +++-
arch/arm64/crypto/sha2-ce-glue.c | 22 ++--
2 files changed, 25 insertions(+), 35 deletions(-)
diff --git a/arch
the consequences.
This reverts commit 7edc86cb1c18b4c274672232117586ea2bef1d9a.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha3-ce-core.S | 81
arch/arm64/crypto/sha3-ce-glue.c | 14 ++--
2 files changed, 39 insertions(+), 56 deletions(-)
diff --git a/arch/arm64
the consequences.
This reverts commit 7df8d164753e6e6f229b72767595072bc6a71f48.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha1-ce-core.S | 47 +++-
arch/arm64/crypto/sha1-ce-glue.c | 22 -
2 files changed, 29 insertions(+), 40 deletions(-)
diff --git a/arch
the consequences.
This reverts commit 6caf7adc5e458f77f550b6c6ca8effa152d61b4a.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/crypto/sha512-ce-core.S | 29 +++
arch/arm64/crypto/sha512-ce-glue.c | 53 ++--
2 files changed, 34 insertions(+), 48 deletions(-)
diff --git a
it applies cleanly to the arm64
tree)
Cc: Dave Martin
Cc: Eric Biggers
Ard Biesheuvel (9):
arm64: assembler: add cond_yield macro
crypto: arm64/sha1-ce - simplify NEON yield
crypto: arm64/sha2-ce - simplify NEON yield
crypto: arm64/sha3-ce - simplify NEON yield
crypto: arm64/sha512-ce
, which would make chunking the input in order to perform the
cond_resched() check from C code disproportionately costly.
Signed-off-by: Ard Biesheuvel
---
arch/arm64/include/asm/assembler.h | 16
1 file changed, 16 insertions(+)
diff --git a/arch/arm64/include/asm/assembler.h
b
On Thu, 28 Jan 2021 at 06:04, Herbert Xu wrote:
>
> On Fri, Jan 22, 2021 at 03:09:52PM +0800, Meng Yu wrote:
> > 1. Add ecc curves(P224, P384, P521) for ECDH;
>
> OK I think this is getting unwieldy.
>
> In light of the fact that we already have hardware that supports
> a specific subset of curves
On Mon, 11 Jan 2021 at 22:31, Ard Biesheuvel wrote:
>
> On Mon, 11 Jan 2021 at 22:05, Eric Biggers wrote:
> >
> > On Mon, Jan 11, 2021 at 05:52:30PM +0100, Ard Biesheuvel wrote:
> > > CRC-T10DIF is a very poor match for the crypto API:
> > > - every user
On Sun, 24 Jan 2021 at 15:23, Ard Biesheuvel wrote:
>
> On Sun, 24 Jan 2021 at 15:10, Stephan Müller wrote:
> >
> > Hi,
> >
> > The key derviation functions are considered to be a cryptographic
> > operation. As cryptographic operations are provided via the k
On Sun, 24 Jan 2021 at 15:28, Helge Deller wrote:
>
> On some of my parisc machines, this patch c055e3eae0f1 ("crypto: xor -
> use ktime for template benchmarking") triggers a dividy-by-zero
> exception because "min" becomes zero, which then leads to a kernel
> crash.
>
> It's not clear yet, why I
On Sun, 24 Jan 2021 at 15:10, Stephan Müller wrote:
>
> Hi,
>
> The key derviation functions are considered to be a cryptographic
> operation. As cryptographic operations are provided via the kernel
> crypto API, this patch set consolidates the KDF implementations into the
> crypto API.
>
> The KD
On Thu, 21 Jan 2021 at 19:05, Eric Biggers wrote:
>
> On Thu, Jan 21, 2021 at 02:07:33PM +0100, Ard Biesheuvel wrote:
> > Salsa20 is not used anywhere in the kernel, is not suitable for disk
> > encryption, and widely considered to have been superseded by ChaCha20.
>
Salsa20 is not used anywhere in the kernel, is not suitable for disk
encryption, and widely considered to have been superseded by ChaCha20.
So let's remove it.
Signed-off-by: Ard Biesheuvel
---
Documentation/admin-guide/device-mapper/dm-integrity.rst |4 +-
crypto/Kc
Tiger is never referenced anywhere in the kernel, and unlikely
to be depended upon by userspace via AF_ALG. So let's remove it.
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 13 -
crypto/Makefile | 1 -
crypto/tcrypt.c | 36 --
crypto/testmgr.c | 18 -
crypto/testmgr.h
RIPE-MD 320 is never referenced anywhere in the kernel, and unlikely
to be depended upon by userspace via AF_ALG. So let's remove it
Signed-off-by: Ard Biesheuvel
---
crypto/Kconfig | 12 -
crypto/ripemd.h | 8 -
crypto/rmd320.c | 391
crypto/tcrypt.c
1 - 100 of 2557 matches
Mail list logo
