On 06.06.2018 16:26, PrasannaKumar Muralidharan wrote: > Hi Herald, > > On 6 June 2018 at 18:18, Harald Freudenberger <fre...@linux.ibm.com> wrote: >> Hello Theodore, hi Linux Community >> >> my patch for the s390 arch_get_random_seed* implementation is about to >> be integrated with the current merge window for kernel 4.18. >> >> So I'd like to start a discussion about a new API for the random.c >> device driver. The current s390 hardware comes with a true hardware >> random generator. This great random source provides high quality >> entropy (100% according to our hardware guys) but is relatively slow. >> >> I want to provide this entropy source to the random pool of the >> random device driver. The only possibility is the implementation of >> the arch_get_random* and arch_get_random_seed* API. So my first attempt >> was to implement the arch_get_random* functions and directly call the >> TRNG. This code made it into the 4.12 kernel and slowed down the >> /dev/urandom performance remarkable. So the first rework removed the >> s390 arch_get_random* implementation and instead provided the >> arch_*_seed functions. The idea was that your good but slow TRNG is >> ideal for providing entropy as seed for pseudo random >> generators. However, as arch_get_random_seed_long() is called very >> frequently in interrupt context and this limits the amount of irqs >> per cpu remarkable (e.g. on heavy network load). As a result my latest >> fix introduces some kind of buffer concept in combination with filling >> the buffer asynchronous with a cascaded TRNG/PRNG. >> >> I am still searching for a way to provide our good hardware entropy >> source to the random pool in the random device driver. So I'd like to >> have a new arch interface which is called when the random pool finds >> out that it is running out of entropy. My feeling is that it should >> not be the only source but should still be mixed with other sources >> of entropy. It should not be able to dominate or occupy the random >> pool but contribute to a significant part. >> >> As nowadays true random generators provide conditioned data usually >> with some kind of hashing algorithm a granularity of 4 or 8 bytes is >> waste of random entropy. The s390 TRNG uses SHA512 and can provide >> 64 bytes entropy with each invocation. Other TRNGs may use sha1 or >> sha256 and so provide 20 or 32 bytes of random. However, the API >> could be something like: >> >> int arch_get_entropy(void *buf, int bufsize); >> >> and the function returns: >> >> < 0 - error, negative errno value >> 0...bufsize - amount of entropy bytes written into the buffer >> may be 0 if there is (currently) no random entropy >> available. No need to fill the buffer, any data in the >> range of 0 up to bufsize is welcome. >> >> random.c could call this api with a buffer of 64 bytes when the >> computed entropy within the pool drops below a threshold limit. >> >> The call should not be done within a userspace process context or >> 'foreign' kernel context (like irqs) but with an own kernel thread >> or workqueue or similar. The data returned should be mixed into >> the pool and counted as entropy. >> >> I think, other architectures could also benefit from such a new >> interface. Power and even x86 have or will have true random entropy >> source hardware and may also like to contribute to the linux random >> device driver. >> >> Does this sound reasonable? If yes, I'll start some investigation and >> try to develop something for random.c. Though this may take some time. >> >> regards and thanks for your time >> Harald Freudenberger >> > hw_rng framework provides entropy to the kernel's entropy pool > already. I am wondering why hw_random interface can't be used for > this. > > Regards, > PrasannaKumar You are right. I was not aware of this API. Thanks I'll give it a try.
regards H.Freudenberger
