linux-stable.git/crypto/aes_generic.c, branch v5.4

crypto: aes-generic - remove unused variable 'rco_tab'

2019-08-15T11:52:14+00:00

crypto/aes_generic.c:64:18: warning:
 rco_tab defined but not used [-Wunused-const-variable=]

It is never used, so can be removed.

Reported-by: Hulk Robot 
Signed-off-by: YueHaibing 
Acked-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: aes-generic - unexport last-round AES tables

2019-07-26T04:58:35+00:00

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 
Signed-off-by: Herbert Xu

crypto: aes-generic - drop key expansion routine in favor of library version

2019-07-26T04:56:06+00:00

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 
Signed-off-by: Herbert Xu

crypto: aes - rename local routines to prevent future clashes

2019-07-26T04:52:03+00:00

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 
Signed-off-by: Herbert Xu

crypto: run initcalls for generic implementations earlier

2019-04-18T14:15:03+00:00

Use subsys_initcall for registration of all templates and generic
algorithm implementations, rather than module_init.  Then change
cryptomgr to use arch_initcall, to place it before the subsys_initcalls.

This is needed so that when both a generic and optimized implementation
of an algorithm are built into the kernel (not loadable modules), the
generic implementation is registered before the optimized one.
Otherwise, the self-tests for the optimized implementation are unable to
allocate the generic implementation for the new comparison fuzz tests.

Note that on arm, a side effect of this change is that self-tests for
generic implementations may run before the unaligned access handler has
been installed.  So, unaligned accesses will crash the kernel.  This is
arguably a good thing as it makes it easier to detect that type of bug.

Signed-off-by: Eric Biggers 
Signed-off-by: Herbert Xu

crypto: aes - Use ___cacheline_aligned for aes data

2019-04-08T06:36:16+00:00

cacheline_aligned is a special section. It cannot be const at the same
time because it's not read-only. It doesn't give any MMU protection.

Mark it ____cacheline_aligned to not place it in a special section,
but just align it in .rodata

Cc: herbert@gondor.apana.org.au
Suggested-by: Rasmus Villemoes 
Signed-off-by: Andi Kleen 
Acked-by: Ard Biesheuvel 
Signed-off-by: Herbert Xu

crypto: arm/aes - add some hardening against cache-timing attacks

2018-11-09T09:36:48+00:00

Make the ARM scalar AES implementation closer to constant-time by
disabling interrupts and prefetching the tables into L1 cache.  This is
feasible because due to ARM's "free" rotations, the main tables are only
1024 bytes instead of the usual 4096 used by most AES implementations.

On ARM Cortex-A7, the speed loss is only about 5%.  The resulting code
is still over twice as fast as aes_ti.c.  Responsiveness is potentially
a concern, but interrupts are only disabled for a single AES block.

Note that even after these changes, the implementation still isn't
necessarily guaranteed to be constant-time; see
https://cr.yp.to/antiforgery/cachetiming-20050414.pdf for a discussion
of the many difficulties involved in writing truly constant-time AES
software.  But it's valuable to make such attacks more difficult.

Much of this patch is based on patches suggested by Ard Biesheuvel.

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

crypto: aes-generic - drop alignment requirement

2017-02-11T09:50:43+00:00

The generic AES code exposes a 32-bit align mask, which forces all
users of the code to use temporary buffers or take other measures to
ensure the alignment requirement is adhered to, even on architectures
that don't care about alignment for software algorithms such as this
one.

So drop the align mask, and fix the code to use get_unaligned_le32()
where appropriate, which will resolve to whatever is optimal for the
architecture.

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

crypto: add missing crypto module aliases

2015-01-13T11:29:11+00:00

Commit 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
changed the automatic module loading when requesting crypto algorithms
to prefix all module requests with "crypto-". This requires all crypto
modules to have a crypto specific module alias even if their file name
would otherwise match the requested crypto algorithm.

Even though commit 5d26a105b5a7 added those aliases for a vast amount of
modules, it was missing a few. Add the required MODULE_ALIAS_CRYPTO
annotations to those files to make them get loaded automatically, again.
This fixes, e.g., requesting 'ecb(blowfish-generic)', which used to work
with kernels v3.18 and below.

Also change MODULE_ALIAS() lines to MODULE_ALIAS_CRYPTO(). The former
won't work for crypto modules any more.

Fixes: 5d26a105b5a7 ("crypto: prefix module autoloading with "crypto-"")
Cc: Kees Cook 
Signed-off-by: Mathias Krause 
Signed-off-by: Herbert Xu

crypto: prefix module autoloading with "crypto-"

2014-11-24T14:43:57+00:00

This prefixes all crypto module loading with "crypto-" so we never run
the risk of exposing module auto-loading to userspace via a crypto API,
as demonstrated by Mathias Krause:

https://lkml.org/lkml/2013/3/4/70

Signed-off-by: Kees Cook 
Signed-off-by: Herbert Xu