Hi Herald, On 6 June 2018 at 18:18, Harald Freudenberger <freude@xxxxxxxxxxxxx> 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
