Am Mittwoch, 1. Juni 2016, 12:59:43 schrieb Herbert Xu: Hi Herbert, > 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. I thought via-rng.c covers the VIA Padlock RNG? Ciao Stephan -- 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
