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

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

On 2024-07-26 20:34, Shunzhi Wen wrote:
>> I'm missing a rationale here. Why is this useful?
>>
> This creates an API for HW that supports cryptographically secure random number generation.
> 
>> 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
>>
> The primary goal of this patch is to provide a direct interface to HW,
> instead of letting kernel handle it. This is not an API just for Arm
> CPUs, as other vendors also have similar HW features. For instance,
> Intel and AMD has support for x86 RDRAND and RDSEED instructions, thus
> can easily implement this API.
> 

No DPDK library (or PMD) currently needs this functionality, and no 
application, to my knowledge, has asked for this. If an app or a DPDK 
library would require cryptographically secure random numbers, it would 
most likely require it on all CPU/OS platforms (and with all DPDK -march 
flags).

RDRAND is only available on certain x86_64 CPUs, and is incredibly slow 
- slower than getting entropy via the kernel, even with non-vDSO syscalls.

Agner Fog lists the RDRAND latency as ~3700 cc for Zen 2. Later 
generations of both AMD and Intel CPUs have much shorter latencies, but 
a reciprocal throughput so low that one have to wait thousands of clock 
cycles before issuing another RDRAND, or risk stalling the core.

My Raptor Lake seems to require ~1000 cc retire RDRAND, which is ~11x 
slower than getting entropy (in bulk) via getentropy().

What is the latency for the ARM equivalent? Does it also have a 
reciprocal throughput issue?

>> 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.
>>
> Regarding the terminology, “cryptographically secure random number”
> is a more accurate and meaningful term than “true random number.”
> This change will be made in the description, and the function name will
> be replaced with rte_csrand.
> 
> IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.