linux.git/arch/arm/crypto, branch v4.13

crypto: arm/crc32 - enable module autoloading based on CPU feature bits

2017-06-01T04:55:42+00:00

Make the module autoloadable by tying it to the CPU feature bits that
describe whether the optional instructions it relies on are implemented
by the current CPU.

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

crypto: arm/sha2-ce - enable module autoloading based on CPU feature bits

2017-06-01T04:55:41+00:00

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

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

crypto: arm/sha1-ce - enable module autoloading based on CPU feature bits

2017-06-01T04:55:40+00:00

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

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

crypto: arm/ghash-ce - enable module autoloading based on CPU feature bits

2017-06-01T04:55:39+00:00

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

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

crypto: arm/aes-ce - enable module autoloading based on CPU feature bits

2017-06-01T04:55:38+00:00

Make the module autoloadable by tying it to the CPU feature bit that
describes whether the optional instructions it relies on are implemented
by the current CPU.

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

crypto: arm/aes-neonbs - resolve fallback cipher at runtime

2017-03-09T10:34:16+00:00

Currently, the bit sliced NEON AES code for ARM has a link time
dependency on the scalar ARM asm implementation, which it uses as a
fallback to perform CBC encryption and the encryption of the initial
XTS tweak.

The bit sliced NEON code is both fast and time invariant, which makes
it a reasonable default on hardware that supports it. However, the
ARM asm code it pulls in is not time invariant, and due to the way it
is linked in, cannot be overridden by the new generic time invariant
driver. In fact, it will not be used at all, given that the ARM asm
code registers itself as a cipher with a priority that exceeds the
priority of the fixed time cipher.

So remove the link time dependency, and allocate the fallback cipher
via the crypto API. Note that this requires this driver's module_init
call to be replaced with late_initcall, so that the (possibly generic)
fallback cipher is guaranteed to be available when the builtin test
is performed at registration time.

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

crypto: arm/crc32 - add build time test for CRC instruction support

2017-03-01T11:47:53+00:00

The accelerated CRC32 module for ARM may use either the scalar CRC32
instructions, the NEON 64x64 to 128 bit polynomial multiplication
(vmull.p64) instruction, or both, depending on what the current CPU
supports.

However, this also requires support in binutils, and as it turns out,
versions of binutils exist that support the vmull.p64 instruction but
not the crc32 instructions.

So refactor the Makefile logic so that this module only gets built if
binutils has support for both.

Signed-off-by: Ard Biesheuvel 
Acked-by: Jon Hunter 
Tested-by: Jon Hunter 
Signed-off-by: Herbert Xu

crypto: arm/crc32 - fix build error with outdated binutils

2017-03-01T11:47:51+00:00

Annotate a vmov instruction with an explicit element size of 32 bits.
This is inferred by recent toolchains, but apparently, older versions
need some help figuring this out.

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

crypto: arm/aes - don't use IV buffer to return final keystream block

2017-02-03T10:16:21+00:00

The ARM bit sliced AES core code uses the IV buffer to pass the final
keystream block back to the glue code if the input is not a multiple of
the block size, so that the asm code does not have to deal with anything
except 16 byte blocks. This is done under the assumption that the outgoing
IV is meaningless anyway in this case, given that chaining is no longer
possible under these circumstances.

However, as it turns out, the CCM driver does expect the IV to retain
a value that is equal to the original IV except for the counter value,
and even interprets byte zero as a length indicator, which may result
in memory corruption if the IV is overwritten with something else.

So use a separate buffer to return the final keystream block.

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

crypto: arm/chacha20 - remove cra_alignmask

2017-02-03T10:16:19+00:00

Remove the unnecessary alignmask: it is much more efficient to deal with
the misalignment in the core algorithm than relying on the crypto API to
copy the data to a suitably aligned buffer.

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