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

[Stephen Hemminger <stephen@networkplumber.org>]

On Sat, 27 Jul 2024 15:45:55 +0000
Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com> wrote:

> Hi Mattias,
> 
> > > 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).
> >   
> 
> I'm sorry, I'm not following this. Are you saying 
> 
> (a) adding a feature someone hasn't already asked for is impossible?
> 
> (b) it is impossible to add support for a feature that is only available in a few CPUs
> of an architecture family?
> 
> > 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?
> >   
> 
> Agree, from the numbers you are showing, it looks like they are all slow and
> unsuitable for the data plane. But aren't there multi-plane DPDK applications
> with control-plane threads that can benefit from a CSRNG, albeit slow?


The issue is that RDRAND and ARM RNG are both hardware features and the
trust level is debatable. (See Wikipedia on RDRAND). The DPDK should stay
out of this security fight because if DPDK offers direct access to HW
RNG then naive vendors will start using it in applications. Then when
it is revealed that some nation state has compromised HW RNG the blame
will land on DPDK for enabling this. Lets not not get into the supply
chain problem here. DPDK is an application environment, not a benchmark
environment.


The answer is to have API's like (rte_csrand) which then call the OS
level primitives. The trust is then passed to the OS. I trust Linus,
Theo de Raadt, and the rest of the open OS community to evaluate and
integrate the best secure random number generator.