Re: Q for a new API for the random device driver
On Wed, Jun 06, 2018 at 04:58:29PM +0200, Harald Freudenberger wrote: > Had a short glimpse to the mentioned add_hwgenerator_randomness() > and this looks in fact like the API I am looking for :-) > Thanks Stephan, I'll write some code and check this out. The more convenient interface would be structure things as a driver under drivers/char/hw_random. The virtio_rng.c driver is a relatively simple one that you can use as a model. That way you don't have "push" randomness at the random pool. Instead, a kernel thread, implemnted in drivers/char/hw_random/core.c, will automatically "pull" randomness from your hardware random number generator when the entropy estimate in the entropy pool falls below the low watermark, and stop when it goes above the high watermark. The arch_get_random/arch_get_random_seed interfaces are intended for this CPU's that have a high-efficiency RNG where getting entropy is "free". But if it is not free, then you only want to draw on the hardware RNG when it is needed and that's what the hw_random infrastructure will do automatically for you. - Ted
Re: Q for a new API for the random device driver
On 06.06.2018 16:26, PrasannaKumar Muralidharan wrote: > Hi Herald, > > On 6 June 2018 at 18:18, Harald Freudenberger 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
Re: Q for a new API for the random device driver
On 06.06.2018 15:11, Stephan Mueller wrote: > Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger: > > Hi Harald, >> 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); > > Why not using the add_hwgenerator_randomness with a kernel thread that is > controlled/spawned from the noise source? > > Ciao > Stephan Had a short glimpse to the mentioned add_hwgenerator_randomness() and this looks in fact like the API I am looking for :-) Thanks Stephan, I'll write some code and check this out. regards H.Freudenberger >
Re: Q for a new API for the random device driver
Hi Herald, On 6 June 2018 at 18:18, Harald Freudenberger 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
Re: Q for a new API for the random device driver
Am Mittwoch, 6. Juni 2018, 14:48:33 CEST schrieb Harald Freudenberger: Hi Harald, > > 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); Why not using the add_hwgenerator_randomness with a kernel thread that is controlled/spawned from the noise source? Ciao Stephan
