On Sun, 27 Oct 2019 at 19:40, Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote: > > On Sun, 27 Oct 2019 at 13:38, Richard Henderson > <richard.henderson@xxxxxxxxxx> wrote: > > > > On 10/24/19 1:57 PM, Ard Biesheuvel wrote: > > >>> + > > >>> +#ifdef CONFIG_ARCH_RANDOM > > >>> + > > >>> +/* > > >>> + * Note that these two interfaces, random and random_seed, are strongly > > >>> + * tied to the Intel instructions RDRAND and RDSEED. RDSEED is the > > >>> + * "enhanced" version and has stronger guarantees. The ARMv8.5-RNG > > >>> + * instruction RNDR corresponds to RDSEED, thus we put our implementation > > >>> + * into the random_seed set of functions. > > >>> + * > > > > > > Is that accurate? The ARM ARM says that RNDR is backed by a DRBG which > > > > > > "" > > > ...is reseeded after an IMPLEMENTATION DEFINED number of random > > > numbers has been generated and read > > > using the RNDR register. > > > """ > > > > > > which means that you cannot rely on this reseeding to take place at all. > > > > > > So the way I read this, RNDR ~= RDRAND and RNDRRS ~= RDSEED, and we > > > should wire up the functions below accordingly. > > > > No, that reading is not correct, and is exactly what I was trying to explain in > > that paragraph. > > > > RNDR ~= RDSEED. > > > > It's a matter of standards conformance: > > > > RDRAND: NIST SP800-90A. > > > > RDSEED: NIST SP800-90B, > > NIST SP800-90C. > > > > RNDR: NIST SP800-90A Rev 1, > > NIST SP800-90B, > > NIST SP800-22, > > FIPS 140-2, > > BSI AIS-31, > > NIST SP800-90C. > > > > That is not what the ARM ARM says (DDI0487E.a K12.1): > > The *TRNG* that seeds the DRBG that backs both RNDR and RNDRRS should conform to > > • The NIST SP800-90B standard. > • The NIST SP800-22 standard. > • The FIPS 140-2 standard. > • The BSI AIS-31 standard. > > This DRBG itself should conform to NIST SP800-90A Rev 1, and is > reseeded at an implementation defined rate when RNDR is used, or every > time when RNDRRS is used. > > So the output of the TRNG itself is not accessible directly, and both > RNDR and RNDRRS return output generated by a DRBG. NIST SP800-90A > suggests a minimum seed size of 440 bits, so using RNDRRS to generate > 64-bit seeds is reasonable, This isn't 100% accurate, but the point is that NIST SP800-90A defines seed sizes for all DRBGs that exceed 64 bits, and so taking at most 64 bits of output from a DRBG seeded with 64+ bits of true entropy is a reasonable approximation of using the seed directly. The downside, of course, is that you need to call the instruction multiple times to get a seed of the mandated size, and so from a certification POV, this may still be problematic. I brought this up some time ago, and suggested that we should have one instruction to produce strong entropy, and one instruction to return the output of the DRBG, with the ability to set the seed explicitly, which would allow the true entropy from the first instruction to be mixed with input from another source, in order to mitigate the trust issues that affect RDRAND/RDSEED. > even though it comes from a DRBG. But RNDR > is definitely not equivalent to RDSEED. >
