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

[Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>]

> -----Original Message-----
> From: Stephen Hemminger <stephen@networkplumber.org>
> Sent: Saturday, July 27, 2024 10:54 AM
> To: Wathsala Wathawana Vithanage <wathsala.vithanage@arm.com>
> Cc: Mattias Rönnblom <hofors@lysator.liu.se>; Shunzhi Wen
> <Shunzhi.Wen@arm.com>; thomas@monjalon.net; Mattias Rönnblom
> <mattias.ronnblom@ericsson.com>; Ruifeng Wang
> <Ruifeng.Wang@arm.com>; Bruce Richardson <bruce.richardson@intel.com>;
> Tyler Retzlaff <roretzla@linux.microsoft.com>; Min Zhou
> <zhoumin@loongson.cn>; David Christensen <drc@linux.ibm.com>; Stanislaw
> Kardach <stanislaw.kardach@gmail.com>; Konstantin Ananyev
> <konstantin.v.ananyev@yandex.ru>; dev@dpdk.org; nd <nd@arm.com>; Jack
> Bond-Preston <Jack.Bond-Preston@arm.com>; Dhruv Tripathi
> <Dhruv.Tripathi@arm.com>; Honnappa Nagarahalli
> <Honnappa.Nagarahalli@arm.com>
> Subject: Re: [PATCH] eal: add support for TRNG with Arm RNG feature
> 
> 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.

Perhaps, you missed my previous email, I understand your concern. Is it acceptable
to you if rte_csrand uses the kernel RNG by default and has a build/run-time
parameter to switch to HW RNG for those who consciously make that decision?