Re: Q for a new API for the random device driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 06.06.2018 16:26, PrasannaKumar Muralidharan wrote:
> 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
You are right. I was not aware of this API. Thanks
I'll give it a try.

regards
H.Freudenberger




[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux