Re: [PATCH] eal: add support for TRNG with Arm RNG feature

["Mattias Rönnblom" <hofors@lysator.liu.se>]

On 2024-07-24 18:16, Stephen Hemminger wrote:

<snip>

>>>>    > +/**
>>>>    > + * Get a true random value.
>>>>    > + *
>>>>    > + * The generator is cryptographically secure.
>>>>
>>>> If you want to extend <rte_random.h> with a cryptographically secure
>>>> random number generator, that's fine.
>>>>
>>>> To have an API that's only available on certain ARM CPUs is not.
>>>>
>>>> NAK
>>>>
>>>> A new function should be called something with "secure", rather than
>>>> "true" (which is a bit silly, since we might well live in a completely
>>>> deterministic universe). "secure" would more clearly communicate the
>>>> intent, and also doesn't imply any particular implementation.
>>>
>>> Agree, with Mattias. What constitutes a secure random number generator
>>> is a matter of much debate. Most of the HW random generators are taking
>>> diode (Schottky noise) and doing transforms on it to get something uniform.
>>>
>>> If a key generation type API was added, why not just use existing and more
>>> researched kernel get_random()?
>>>    
>>
>> Ideally, you want to avoid system calls on lcore workers doing packet
>> processing. If you have to do system calls (which I believe is the case
>> here), it's better to a simple call, not so often.
>>
>> getentropy() seems to need about 800 core clock cycles on my x86_64, on
>> average. (rte_rand() needs ~11 cc/call.) 800 cc is not too horrible, but
>> system calls tend to have some pretty bad tail latencies.
>>
>> To improve efficiency, one could do a getentropy() on a relatively large
>> buffer, and cache the result on a per-lcore basis, amortizing the system
>> call overhead over many calls.
>>
>> You still have the tail latency issue to deal with. We could have a
>> control thread providing entropy for the lcores, but that seems like
>> massive overkill.
> 
> 
> Getrandom is a vsyscall on current kernels, and it manages use of entropy across
> multiple sources. If you are doing lots of key generation, you don't want to
> hit the hardware every time.
> 
> https://lwn.net/Articles/974468/
> 
> 

If I understand things correctly, the getrandom() vDSO support was 
mainlined *today*, so you need to be current indeed to have a vDSO 
getrandom(). :)

The above benchmark (rand_perf_autotest with rte_rand() implemented with 
getentropy()) was run on Linux 5.15 and glibc 2.35, so a regular system 
call was used.

(getentropy() delegates to getrandom(), so the performance is the same.)