linux.git/drivers/crypto/caam, branch v5.7-rc2

crypto: caam - limit single JD RNG output to maximum of 16 bytes

2020-03-30T00:50:50+00:00

In order to follow recommendation in SP800-90C (section "9.4 The
Oversampling-NRBG Construction") limit the output of "generate" JD
submitted to CAAM. See
https://lore.kernel.org/linux-crypto/VI1PR0402MB3485EF10976A4A69F90E5B0F98580@VI1PR0402MB3485.eurprd04.prod.outlook.com/
for more details.

This change should make CAAM's hwrng driver good enough to have 1024
quality rating.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Horia Geantă 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu

crypto: caam - enable prediction resistance in HRWNG

2020-03-30T00:50:50+00:00

Instantiate CAAM RNG with prediction resistance enabled to improve its
quality (with PR on DRNG is forced to reseed from TRNG every time
random data is generated).

Management Complex firmware with version lower than 10.20.0
doesn't provide prediction resistance support. Consider this
and only instantiate rng when mc f/w version is lower.

Signed-off-by: Andrey Smirnov 
Signed-off-by: Andrei Botila 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - invalidate entropy register during RNG initialization

2020-03-30T00:50:49+00:00

In order to make sure that we always use non-stale entropy data, change
the code to invalidate entropy register during RNG initialization.

Signed-off-by: Aymen Sghaier 
Signed-off-by: Vipul Kumar 
[andrew.smirnov@gmail.com ported to upstream kernel, rewrote commit msg]
Signed-off-by: Andrey Smirnov 
Reviewed-by: Horia Geantă 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu

crypto: caam - check if RNG job failed

2020-03-30T00:50:49+00:00

We shouldn't stay silent if RNG job fails. Add appropriate code to
check for that case and propagate error code up appropriately.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Horia Geantă 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu

crypto: caam - simplify RNG implementation

2020-03-30T00:50:49+00:00

Rework CAAM RNG implementation as follows:

- Make use of the fact that HWRNG supports partial reads and will
handle such cases gracefully by removing recursion in caam_read()

- Convert blocking caam_read() codepath to do a single blocking job
read directly into requested buffer, bypassing any intermediary
buffers

- Convert async caam_read() codepath into a simple single
reader/single writer FIFO use-case, thus simplifying concurrency
handling and delegating buffer read/write position management to KFIFO
subsystem.

- Leverage the same low level RNG data extraction code for both async
and blocking caam_read() scenarios, get rid of the shared job
descriptor and make non-shared one as a simple as possible (just
HEADER + ALGORITHM OPERATION + FIFO STORE)

- Split private context from DMA related memory, so that the former
could be allocated without GFP_DMA.

NOTE: On its face value this commit decreased throughput numbers
reported by

  dd if=/dev/hwrng of=/dev/null bs=1 count=100K [iflag=nonblock]

by about 15%, however commits that enable prediction resistance and
limit JR total size impact the performance so much and move the
bottleneck such as to make this regression irrelevant.

NOTE: On the bright side, this commit reduces RNG in kernel DMA buffer
memory usage from 2 x RN_BUF_SIZE (~256K) to 32K.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Horia Geantă 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu

crypto: caam - drop global context pointer and init_done

2020-03-30T00:50:49+00:00

Leverage devres to get rid of code storing global context as well as
init_done flag.

Original code also has a circular deallocation dependency where
unregister_algs() -> caam_rng_exit() -> caam_jr_free() chain would
only happen if all of JRs were freed. Fix this by moving
caam_rng_exit() outside of unregister_algs() and doing it specifically
for JR that instantiated HWRNG.

Signed-off-by: Andrey Smirnov 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam - use struct hwrng's .init for initialization

2020-03-30T00:50:49+00:00

Make caamrng code a bit more symmetric by moving initialization code
to .init hook of struct hwrng.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Horia Geantă 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Cc: linux-imx@nxp.com
Signed-off-by: Herbert Xu

crypto: caam - allocate RNG instantiation descriptor with GFP_DMA

2020-03-30T00:50:48+00:00

Be consistent with the rest of the codebase and use GFP_DMA when
allocating memory for a CAAM JR descriptor.

Signed-off-by: Andrey Smirnov 
Reviewed-by: Horia Geantă 
Cc: Chris Healy 
Cc: Lucas Stach 
Cc: Horia Geantă 
Cc: Herbert Xu 
Cc: Iuliana Prodan 
Cc: linux-imx@nxp.com
Cc: linux-crypto@vger.kernel.org
Cc: linux-kernel@vger.kernel.org
Signed-off-by: Herbert Xu

crypto: caam - update xts sector size for large input length

2020-03-06T01:28:25+00:00

Since in the software implementation of XTS-AES there is
no notion of sector every input length is processed the same way.
CAAM implementation has the notion of sector which causes different
results between the software implementation and the one in CAAM
for input lengths bigger than 512 bytes.
Increase sector size to maximum value on 16 bits.

Fixes: c6415a6016bf ("crypto: caam - add support for acipher xts(aes)")
Cc:  # v4.12+
Signed-off-by: Andrei Botila 
Reviewed-by: Horia Geantă 
Signed-off-by: Herbert Xu

crypto: caam/qi2 - fix chacha20 data size error

2020-03-06T01:28:25+00:00

HW generates a Data Size error for chacha20 requests that are not
a multiple of 64B, since algorithm state (AS) does not have
the FINAL bit set.

Since updating req->iv (for chaining) is not required,
modify skcipher descriptors to set the FINAL bit for chacha20.

[Note that for skcipher decryption we know that ctx1_iv_off is 0,
which allows for an optimization by not checking algorithm type,
since append_dec_op1() sets FINAL bit for all algorithms except AES.]

Also drop the descriptor operations that save the IV.
However, in order to keep code logic simple, things like
S/G tables generation etc. are not touched.

Cc:  # v5.3+
Fixes: 334d37c9e263 ("crypto: caam - update IV using HW support")
Signed-off-by: Horia Geantă 
Tested-by: Valentin Ciocoi Radulescu 
Signed-off-by: Herbert Xu