> -----Original Message----- > From: Stephen Hemminger <step...@networkplumber.org> > Sent: Saturday, July 27, 2024 10:54 AM > To: Wathsala Wathawana Vithanage <wathsala.vithan...@arm.com> > Cc: Mattias Rönnblom <hof...@lysator.liu.se>; Shunzhi Wen > <shunzhi....@arm.com>; tho...@monjalon.net; Mattias Rönnblom > <mattias.ronnb...@ericsson.com>; Ruifeng Wang > <ruifeng.w...@arm.com>; Bruce Richardson <bruce.richard...@intel.com>; > Tyler Retzlaff <roret...@linux.microsoft.com>; Min Zhou > <zhou...@loongson.cn>; David Christensen <d...@linux.ibm.com>; Stanislaw > Kardach <stanislaw.kard...@gmail.com>; Konstantin Ananyev > <konstantin.v.anan...@yandex.ru>; dev@dpdk.org; nd <n...@arm.com>; Jack > Bond-Preston <jack.bond-pres...@arm.com>; Dhruv Tripathi > <dhruv.tripa...@arm.com>; Honnappa Nagarahalli > <honnappa.nagaraha...@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.vithan...@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?
