linux-toradex.git/drivers/crypto, branch v4.9.52

crypto: ccp - Fix XTS-AES-128 support on v5 CCPs

2017-09-27T12:39:20+00:00

commit e652399edba99a5497f0d80f240c9075d3b43493 upstream.

Version 5 CCPs have some new requirements for XTS-AES: the type field
must be specified, and the key requires 512 bits, with each part
occupying 256 bits and padded with zeroes.

Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ixp4xx - Fix error handling path in 'aead_perform()'

2017-08-25T00:12:18+00:00

commit 28389575a8cf933a5f3c378556b9f4d3cce0efd2 upstream.

In commit 0f987e25cb8a, the source processing has been moved in front of
the destination processing, but the error handling path has not been
modified accordingly.
Free resources in the correct order to avoid some leaks.

Fixes: 0f987e25cb8a ("crypto: ixp4xx - Fix false lastlen uninitialised warning")
Reported-by: Christophe JAILLET 
Signed-off-by: Herbert Xu 
Reviewed-by: Arnd Bergmann 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - fix signals handling

2017-07-21T05:42:23+00:00

commit 7459e1d25ffefa2b1be799477fcc1f6c62f6cec7 upstream.

Driver does not properly handle the case when signals interrupt
wait_for_completion_interruptible():
-it does not check for return value
-completion structure is allocated on stack; in case a signal interrupts
the sleep, it will go out of scope, causing the worker thread
(caam_jr_dequeue) to fail when it accesses it

wait_for_completion_interruptible() is replaced with uninterruptable
wait_for_completion().
We choose to block all signals while waiting for I/O (device executing
the split key generation job descriptor) since the alternative - in
order to have a deterministic device state - would be to flush the job
ring (aborting *all* in-progress jobs).

Fixes: 045e36780f115 ("crypto: caam - ahash hmac support")
Fixes: 4c1ec1f930154 ("crypto: caam - refactor key_gen, sg")
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - properly set IV after {en,de}crypt

2017-07-21T05:42:23+00:00

commit 854b06f768794cd664886ec3ba3a5b1c58d42167 upstream.

Certain cipher modes like CTS expect the IV (req->info) of
ablkcipher_request (or equivalently req->iv of skcipher_request) to
contain the last ciphertext block when the {en,de}crypt operation is done.
This is currently not the case for the CAAM driver which in turn breaks
e.g. cts(cbc(aes)) when the CAAM driver is enabled.

This patch fixes the CAAM driver to properly set the IV after the
{en,de}crypt operation of ablkcipher finishes.

This issue was revealed by the changes in the SW CTS mode in commit
0605c41cc53ca ("crypto: cts - Convert to skcipher")

Signed-off-by: David Gstir 
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: atmel - only treat EBUSY as transient if backlog

2017-07-21T05:42:23+00:00

commit 1606043f214f912a52195293614935811a6e3e53 upstream.

The Atmel SHA driver was treating -EBUSY as indication of queueing
to backlog without checking that backlog is enabled for the request.

Fix it by checking request flags.

Signed-off-by: Gilad Ben-Yossef 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: talitos - Extend max key length for SHA384/512-HMAC and AEAD

2017-07-21T05:42:23+00:00

commit 03d2c5114c95797c0aa7d9f463348b171a274fd4 upstream.

An updated patch that also handles the additional key length requirements
for the AEAD algorithms.

The max keysize is not 96.  For SHA384/512 it's 128, and for the AEAD
algorithms it's longer still.  Extend the max keysize for the
AEAD size for AES256 + HMAC(SHA512).

Fixes: 357fb60502ede ("crypto: talitos - add sha224, sha384 and sha512 to existing AEAD algorithms")
Signed-off-by: Martin Hicks 
Acked-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: caam - fix gfp allocation flags (part I)

2017-07-15T10:16:16+00:00

commit 42cfcafb91dabb0f9d9e08396c39824535948c67 upstream.

Changes in the SW cts (ciphertext stealing) code in
commit 0605c41cc53ca ("crypto: cts - Convert to skcipher")
revealed a problem in the CAAM driver:
when cts(cbc(aes)) is executed and cts runs in SW,
cbc(aes) is offloaded in CAAM; cts encrypts the last block
in atomic context and CAAM incorrectly decides to use GFP_KERNEL
for memory allocation.

Fix this by allowing GFP_KERNEL (sleeping) only when MAY_SLEEP flag is
set, i.e. remove MAY_BACKLOG flag.

We split the fix in two parts - first is sent to -stable, while the
second is not (since there is no known failure case).

Link: http://lkml.kernel.org/g/20170602122446.2427-1-david@sigma-star.at
Reported-by: David Gstir 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Change ISR handler method for a v5 CCP

2017-05-20T12:28:37+00:00

commit 6263b51eb3190d30351360fd168959af7e3a49a9 upstream.

The CCP has the ability to perform several operations simultaneously,
but only one interrupt.  When implemented as a PCI device and using
MSI-X/MSI interrupts, use a tasklet model to service interrupts. By
disabling and enabling interrupts from the CCP, coupled with the
queuing that tasklets provide, we can ensure that all events
(occurring on the device) are recognized and serviced.

This change fixes a problem wherein 2 or more busy queues can cause
notification bits to change state while a (CCP) interrupt is being
serviced, but after the queue state has been evaluated. This results
in the event being 'lost' and the queue hanging, waiting to be
serviced. Since the status bits are never fully de-asserted, the
CCP never generates another interrupt (all bits zero -> one or more
bits one), and no further CCP operations will be executed.

Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Change ISR handler method for a v3 CCP

2017-05-20T12:28:37+00:00

commit 7b537b24e76a1e8e6d7ea91483a45d5b1426809b upstream.

The CCP has the ability to perform several operations simultaneously,
but only one interrupt.  When implemented as a PCI device and using
MSI-X/MSI interrupts, use a tasklet model to service interrupts. By
disabling and enabling interrupts from the CCP, coupled with the
queuing that tasklets provide, we can ensure that all events
(occurring on the device) are recognized and serviced.

This change fixes a problem wherein 2 or more busy queues can cause
notification bits to change state while a (CCP) interrupt is being
serviced, but after the queue state has been evaluated. This results
in the event being 'lost' and the queue hanging, waiting to be
serviced. Since the status bits are never fully de-asserted, the
CCP never generates another interrupt (all bits zero -> one or more
bits one), and no further CCP operations will be executed.

Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman

crypto: ccp - Disable interrupts early on unload

2017-05-20T12:28:37+00:00

commit 116591fe3eef11c6f06b662c9176385f13891183 upstream.

Ensure that we disable interrupts first when shutting down
the driver.

Signed-off-by: Gary R Hook 
Signed-off-by: Herbert Xu 
Signed-off-by: Greg Kroah-Hartman