[v5,0/4] enable CAAM's HWRNG as default

Message

Andrey Smirnov Dec. 3, 2019, 4:23 p.m. UTC

Everyone:

This series is a continuation of original [discussion]. I don't know
if what's in the series is enough to use CAAMs HWRNG system wide, but
I am hoping that with enough iterations and feedback it will be.

Changes since [v1]:

    - Original hw_random replaced with the one using output of TRNG directly

    - SEC4 DRNG IP block exposed via crypto API

    - Small fix regarding use of GFP_DMA added to the series

Chagnes since [v2]:

    - msleep in polling loop to avoid wasting CPU cycles

    - caam_trng_read() bails out early if 'wait' is set to 'false'

    - fixed typo in ZII's name

Changes since [v3]:

    - DRNG's .cra_name is now "stdrng"

    - collected Reviewd-by tag from Lucas

    - typo fixes in commit messages of the series

Changes since [v4]:

    - Dropped "crypto: caam - RNG4 TRNG errata" and "crypto: caam -
      enable prediction resistance in HRWNG" to limit the scope of the
      series. Those two patches are not yet ready and can be submitted
      separately later.

    - Collected Tested-by from Chris

Feedback is welcome!

Thanks,
Andrey Smirnov

[discussion] https://patchwork.kernel.org/patch/9850669/
[v1] https://lore.kernel.org/lkml/[e-mail]
[v2] https://lore.kernel.org/lkml/[e-mail]
[v3] https://lore.kernel.org/lkml/[e-mail]
[v4] https://lore.kernel.org/lkml/[e-mail]

Andrey Smirnov (4):
  crypto: caam - allocate RNG instantiation descriptor with GFP_DMA
  crypto: caam - move RNG presence check into a shared function
  crypto: caam - replace DRNG with TRNG for use with hw_random
  crypto: caam - expose SEC4 DRNG via crypto RNG API

 drivers/crypto/caam/Kconfig   |  15 +-
 drivers/crypto/caam/Makefile  |   3 +-
 drivers/crypto/caam/caamrng.c | 358 ----------------------------------
 drivers/crypto/caam/ctrl.c    |  10 +-
 drivers/crypto/caam/drng.c    | 174 +++++++++++++++++
 drivers/crypto/caam/intern.h  |  32 ++-
 drivers/crypto/caam/jr.c      |   3 +-
 drivers/crypto/caam/regs.h    |  11 +-
 drivers/crypto/caam/trng.c    |  89 +++++++++
 9 files changed, 320 insertions(+), 375 deletions(-)
 delete mode 100644 drivers/crypto/caam/caamrng.c
 create mode 100644 drivers/crypto/caam/drng.c
 create mode 100644 drivers/crypto/caam/trng.c

Comments

Horia Geanta Dec. 9, 2019, 3:44 p.m. UTC | #1

On 12/3/2019 6:24 PM, Andrey Smirnov wrote:
> Everyone:
> 
> This series is a continuation of original [discussion]. I don't know
> if what's in the series is enough to use CAAMs HWRNG system wide, but
> I am hoping that with enough iterations and feedback it will be.
> 
> Changes since [v1]:
> 
>     - Original hw_random replaced with the one using output of TRNG directly
> 
>     - SEC4 DRNG IP block exposed via crypto API
> 
>     - Small fix regarding use of GFP_DMA added to the series
> 
> Chagnes since [v2]:
> 
>     - msleep in polling loop to avoid wasting CPU cycles
> 
>     - caam_trng_read() bails out early if 'wait' is set to 'false'
> 
>     - fixed typo in ZII's name
> 
> Changes since [v3]:
> 
>     - DRNG's .cra_name is now "stdrng"
> 
>     - collected Reviewd-by tag from Lucas
> 
>     - typo fixes in commit messages of the series
> 
> Changes since [v4]:
> 
>     - Dropped "crypto: caam - RNG4 TRNG errata" and "crypto: caam -
>       enable prediction resistance in HRWNG" to limit the scope of the
>       series. Those two patches are not yet ready and can be submitted
>       separately later.
> 
I don't agree with dropping the Job Ring Interface (JRI) in favor of
using TRNG registers directly - for the purpose of extracting entropy.

One of the reasons is that TRNG registers are part of page 0,
which is not accessible in the Linux kernel in some cases.

It's possible to use JRI for extracting entropy following these steps:

1. Instantiate RNG state handle with Prediction Resistance (PR) support
This is optional in cases when page 0 is not under kernel's control.
We'll separately modify SW controlling page 0 to offer PR support.

2. For each hwrng read(), enqueue via JRI one or more job descriptors (JD)
having the PR bit set in the ALGORITHM OPERATION command.

Note that according to hwrng API, it's ok to *partially* fulfill the request:
 * @read:		New API. drivers can fill up to max bytes of data
 *			into the buffer. The buffer is aligned for any type
 *			and max is a multiple of 4 and >= 32 bytes.

It's important to limit the output of each JD, such that the recommendation
in SP800-90C (section "9.4 The Oversampling-NRBG Construction") is followed:
https://csrc.nist.gov/CSRC/media/Publications/sp/800-90c/draft/documents/sp800_90c_second_draft.pdf

For CAAM RNG4, the DRBG security strength is s = 256 bits (32 bytes),
thus each JD must extract at most s/2 - 128 bits (16 bytes).

Similar to what's being done for TRNG registers-based implementation,
some back-off mechanism is needed, such that DECO won't stall
waiting for the TRNG.
This is important on i.MX platforms where there's a single DECO
(on PPC & Layerscape platforms there are multiple DECOs).

Horia