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

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Mattias Rönnblom [mailto:hofors@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.