linux.git/drivers/crypto/caam, branch v4.13-rc2

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

2017-07-12T10:38:07+00:00

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")

Cc:  # 4.8+
Signed-off-by: David Gstir 
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - fix signals handling

2017-07-12T10:38:04+00:00

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).

Cc: 
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

Merge git://git.kernel.org/pub/scm/linux/kernel/git/herbert/crypto-2.6

2017-07-05T07:17:26+00:00

Merge the crypto tree to pull in fixes for the next merge window.

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

2017-06-22T08:47:23+00:00

This is the 2nd part of fixing the usage of GFP_KERNEL for memory
allocations, taking care off all the places that haven't caused a real
problem / failure.
Again, the issue being fixed is that GFP_KERNEL should be used only when
MAY_SLEEP flag is set, i.e. MAY_BACKLOG flag usage is orthogonal.

Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu

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

2017-06-22T08:47:22+00:00

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
Cc:  # 4.8+
Reported-by: David Gstir 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - make of_device_ids const.

2017-06-20T03:21:49+00:00

of_device_ids are not supposed to change at runtime. All functions
working with of_device_ids provided by  work with const
of_device_ids. So mark the non-const structs as const.

File size before:
   text	   data	    bss	    dec	    hex	filename
   2376	    808	    128	   3312	    cf0	drivers/crypto/caam/jr.o

File size after constify caam_jr_match:
   text	   data	    bss	    dec	    hex	filename
   2976	    192	    128	   3296	    ce0	drivers/crypto/caam/jr.o

Signed-off-by: Arvind Yadav 
Signed-off-by: Herbert Xu

crypto: caampkc - comply with crypto_akcipher_maxsize()

2017-06-10T04:04:30+00:00

crypto_akcipher_maxsize() asks for the output buffer size without
caring for errors. It allways assume that will be called after
a valid setkey. Comply with it and return what he wants.

Signed-off-by: Tudor Ambarus 
Signed-off-by: Herbert Xu

crypto: caam - add support for RSA key form 3

2017-05-18T05:19:51+00:00

CAAM RSA private key may have either of three representations.

1. The first representation consists of the pair (n, d), where the
   components have the following meanings:
      n      the RSA modulus
      d      the RSA private exponent

2. The second representation consists of the triplet (p, q, d), where
the
   components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      d      the RSA private exponent

3. The third representation consists of the quintuple (p, q, dP, dQ,
qInv),
   where the components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      dP     the first factors's CRT exponent
      dQ     the second factors's CRT exponent
      qInv   the (first) CRT coefficient

The benefit of using the third or the second key form is lower
computational cost for the decryption and signature operations.

This patch adds support for the third RSA private key
representations and extends caampkc to use the fastest key when all
related components are present in the private key.

Signed-off-by: Tudor Ambarus 
Signed-off-by: Radu Alexe 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - add support for RSA key form 2

2017-05-18T05:19:51+00:00

CAAM RSA private key may have either of three representations.

1. The first representation consists of the pair (n, d), where the
   components have the following meanings:
      n      the RSA modulus
      d      the RSA private exponent

2. The second representation consists of the triplet (p, q, d), where
the
   components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      d      the RSA private exponent

3. The third representation consists of the quintuple (p, q, dP, dQ,
qInv),
   where the components have the following meanings:
      p      the first prime factor of the RSA modulus n
      q      the second prime factor of the RSA modulus n
      dP     the first factors's CRT exponent
      dQ     the second factors's CRT exponent
      qInv   the (first) CRT coefficient

The benefit of using the third or the second key form is lower
computational cost for the decryption and signature operations.

This patch adds support for the second RSA private key
representation.

Signed-off-by: Tudor Ambarus 
Signed-off-by: Radu Alexe 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - incapsulate dropping leading zeros into function

2017-05-18T05:19:50+00:00

This function will be used into further patches.

Signed-off-by: Radu Alexe 
Signed-off-by: Horia Geantă 
Signed-off-by: Herbert Xu