> From: Mattias Rönnblom [mailto:hof...@lysator.liu.se] > Sent: Monday, 29 July 2024 21.12 > > On 2024-07-29 20:16, Wathsala Wathawana Vithanage wrote: > >> > >> Without a rationale why rte_csrand() functionality is something that > should be > >> in DPDK, and a rationale why the ARM CPU CSRNG is superior to > getentropy(), > >> it doesn't really matter how the patch set looks like. > >> > >> I've repeatedly asked for this information, and you've repeatedly > ignored it. > >> This does not further your cause. > >> > > > > I don't want to get into a debate on what's more superior because DPDK > already have similar > > Setups, take OpenSSL and Marvell's security accelerator for instance. > Rationale is simple it boils > > down to freedom of choice. > > > > I have been reiterating that I'm ready to make Kernel getrandom() the > default in rte_csrand() > > and HW RNG (not limited Arm) a build time option along with your other > demands for various > > optimizations. Having a build time option to enable HW CSRNG doesn't > hinder your freedom to > > choose a CSRNG implementation of your linking. > > Neither you nor I are in a place to decide what's right for others; > the best we can do is to > > collaborate on providing them with options. Leave the decision to > users, application developers, > > and integrators. > > > > I believe that the coexistence of support for OpenSSL and other HW > security accelerators in > > DPDK already establishes rationale and precedent. > > > > > > I feel no obligation to offer (potentially relatively uninformed) DPDK > users with options which I suspect have no benefits, only drawbacks. In > the x86_64 HW RNG case, I think it's fair to say we *know* it's bad idea > to use it as a high-performance CSRNG. In the ARM case, you choose to > leave us in the dark, so I can only assume it looks similar there. > > The typical networking SoC's crypto-related hardware offload can pretty > much always demonstrate benefits.
I have been following this discussion, and tend to agree with Mattias and Stephen. However, I'll take another view at it from a different angle. DPDK already offers other crypto functions through the crypto drivers. So DPDK is already in the crypto space. getentropy() is not available on Windows, so adding a cross-platform cryptographically secure random number generator function to DPDK could be useful. However, the rte_random functions in the EAL is for high-speed pseudo-random number generation, not for crypto use. No crypto functions - not even true random number generation - belong in the EAL, but in a crypto library. Repeat: No crypto in EAL! So, either add the new true random number generator as some sort of crypto driver, or add a new crypto library for true random number generation. Regarding the API, having a 64 bit true random number generator is useless for crypto purposes; the function needs to generate a sequence of random bytes for crypto initialization vectors and similar. It could have an API resembling this: int rte_crypto_random(char * const buf, size_t num); However, as Mattias mentions, the underlying implementation must support typical networking SoC's crypto-related hardware offload to be practically useful. In other words: It is not as simple as we wish for. It seems some sort of "true random generator" driver infrastructure might be required for such SoC hardware offloads.
