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
