Jeffrey Walton <noloader@xxxxxxxxx> wrote: > Please forgive my ignorance here... > > I have test system with a VIA C7-M processor and PM-400 chipset. This > is one of those Thin Client/Internet of Things processor and chipsets > I test security libraries on (like OpenSSL, Cryptlib and Crypto++). > > The processor includes the Padlock extensions. Padlock is similar to > Intel's RDRAND, RDSEED and AES-NI, and it predates Intel's > instructions by about a decade. > > The Padlock Security Engine can produce a stream of random numbers at > megabits per socond, so I've been kind of surprised it has been > suffering entropy depletion. Here's what the audit trail looks like: > > Testing operating system provided blocking random number generator... > FAILED: it took 74 seconds to generate 5 bytes > passed: 5 generated bytes compressed to 7 bytes by DEFLATE > > Above, the blocking RNG is drained. Then, 16 bytes are requested. It > appears to take over one minute to gather five bytes when effectively > an endless stream is available. > > My question is, is this system expected to suffer entropy depletion > out of the box? Or are users expected to do something special so the > system does not fail? I don't think anybody has written either an hwrng driver or a rdrand hook for padlock. Patches are welcome. Cheers, -- Email: Herbert Xu <herbert@xxxxxxxxxxxxxxxxxxx> Home Page: http://gondor.apana.org.au/~herbert/ PGP Key: http://gondor.apana.org.au/~herbert/pubkey.txt -- To unsubscribe from this list: send the line "unsubscribe linux-crypto" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
