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.)
