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
