linux.git/crypto, branch v5.11-rc2

crypto: aegis128 - avoid spurious references crypto_aegis128_update_simd

2020-12-04T07:16:53+00:00

Geert reports that builds where CONFIG_CRYPTO_AEGIS128_SIMD is not set
may still emit references to crypto_aegis128_update_simd(), which
cannot be satisfied and therefore break the build. These references
only exist in functions that can be optimized away, but apparently,
the compiler is not always able to prove this.

So add some explicit checks for CONFIG_CRYPTO_AEGIS128_SIMD to help the
compiler figure this out.

Tested-by: Geert Uytterhoeven 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: seed - remove trailing semicolon in macro definition

2020-12-04T07:13:16+00:00

The macro use will already have a semicolon.

Signed-off-by: Tom Rix 
Signed-off-by: Herbert Xu

crypto: ecdh - avoid unaligned accesses in ecdh_set_secret()

2020-12-04T07:13:13+00:00

ecdh_set_secret() casts a void* pointer to a const u64* in order to
feed it into ecc_is_key_valid(). This is not generally permitted by
the C standard, and leads to actual misalignment faults on ARMv6
cores. In some cases, these are fixed up in software, but this still
leads to performance hits that are entirely avoidable.

So let's copy the key into the ctx buffer first, which we will do
anyway in the common case, and which guarantees correct alignment.

Cc: 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: tcrypt - include 1420 byte blocks in aead and skcipher benchmarks

2020-11-27T06:13:45+00:00

WireGuard and IPsec both typically operate on input blocks that are
~1420 bytes in size, given the default Ethernet MTU of 1500 bytes and
the overhead of the VPN metadata.

Many aead and sckipher implementations are optimized for power-of-2
block sizes, and whether they perform well when operating on 1420
byte blocks cannot be easily extrapolated from the performance on
power-of-2 block size. So let's add 1420 bytes explicitly, and round
it up to the next blocksize multiple of the algo in question if it
does not support 1420 byte blocks.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: tcrypt - permit tcrypt.ko to be builtin

2020-11-27T06:13:45+00:00

When working on crypto algorithms, being able to run tcrypt quickly
without booting an entire Linux installation can be very useful. For
instance, QEMU/kvm can be used to boot a kernel from the command line,
and having tcrypt.ko builtin would allow tcrypt to be executed to run
benchmarks, or to run tests for algorithms that need to be instantiated
from templates, without the need to make it past the point where the
rootfs is mounted.

So let's relax the requirement that tcrypt can only be built as a module
when CONFIG_EXPERT is enabled.

Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: tcrypt - don't initialize at subsys_initcall time

2020-11-27T06:13:44+00:00

Commit c4741b2305979 ("crypto: run initcalls for generic implementations
earlier") converted tcrypt.ko's module_init() to subsys_initcall(), but
this was unintentional: tcrypt.ko currently cannot be built into the core
kernel, and so the subsys_initcall() gets converted into module_init()
under the hood. Given that tcrypt.ko does not implement a generic version
of a crypto algorithm that has to be available early during boot, there
is no point in running the tcrypt init code earlier than implied by
module_init().

However, for crypto development purposes, we will lift the restriction
that tcrypt.ko must be built as a module, and when builtin, it makes sense
for tcrypt.ko (which does its work inside the module init function) to run
as late as possible. So let's switch to late_initcall() instead.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Eric Biggers 
Signed-off-by: Herbert Xu

crypto: aegis128 - expose SIMD code path as separate driver

2020-11-27T06:13:40+00:00

Wiring the SIMD code into the generic driver has the unfortunate side
effect that the tcrypt testing code cannot distinguish them, and will
therefore not use the latter to fuzz test the former, as it does for
other algorithms.

So let's refactor the code a bit so we can register two implementations:
aegis128-generic and aegis128-simd.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Ondrej Mosnacek 
Signed-off-by: Herbert Xu

crypto: aegis128/neon - move final tag check to SIMD domain

2020-11-27T06:13:40+00:00

Instead of calculating the tag and returning it to the caller on
decryption, use a SIMD compare and min across vector to perform
the comparison. This is slightly more efficient, and removes the
need on the caller's part to wipe the tag from memory if the
decryption failed.

While at it, switch to unsigned int when passing cryptlen and
assoclen - we don't support input sizes where it matters anyway.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Ondrej Mosnacek 
Signed-off-by: Herbert Xu

crypto: aegis128/neon - optimize tail block handling

2020-11-27T06:13:39+00:00

Avoid copying the tail block via a stack buffer if the total size
exceeds a single AEGIS block. In this case, we can use overlapping
loads and stores and NEON permutation instructions instead, which
leads to a modest performance improvement on some cores (< 5%),
and is slightly cleaner. Note that we still need to use a stack
buffer if the entire input is smaller than 16 bytes, given that
we cannot use 16 byte NEON loads and stores safely in this case.

Signed-off-by: Ard Biesheuvel 
Reviewed-by: Ondrej Mosnacek 
Signed-off-by: Herbert Xu

crypto: aegis128 - wipe plaintext and tag if decryption fails

2020-11-27T06:13:39+00:00

The AEGIS spec mentions explicitly that the security guarantees hold
only if the resulting plaintext and tag of a failed decryption are
withheld. So ensure that we abide by this.

While at it, drop the unused struct aead_request *req parameter from
crypto_aegis128_process_crypt().

Reviewed-by: Ondrej Mosnacek 
Signed-off-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu