Arm Really Should Standardize An SMC Interface For Hardware Random Number Generators

Intel and AMD have added RDRAND a long time ago. IBM added the (awesomely named) DARN instruction to POWER9.

What do we have on AArch64? A mess. Ad-hoc drivers for specific RNGs, specified in device trees and (OMG) ACPI tables with device tree pieces in them.

Some vendors, instead of providing RNG device descriptions, have started using Secure Monitor Calls. This is a better interface for the OS. It's pretty much "just an instruction" like RDRAND, except instead of a hardcoded ISA instruction it's some parameters to the smc instruction. Since SMC handlers are implemented in firmware/software, this does not require new silicon like an RDRAND type ISA instruction might.

• Amazon (AWS) Graviton: a recently posted Linux patch indicates they're planning to use an SMCCC call to get entropy from the hypervisor
• NXP Layerscape: I recently found this on codeaurora: SMC "server" side, EFI "client" side
• Nintendo Switch: not an open system (officially), but they do use SMC for RNG, there's a reimplementation in Atmosphere custom firmware. Interestingly, they seem provide it to EL0 too.

But this is still a bunch of vendor-specific calls.

Arm did an amazing job standardizing the interrupt controller, timer, watchdog, serial console, etc. Can we get a similarly standardized SMCCC call for getting entropy?

As a FreeBSD contributor, I would much prefer having to write one "Generic SMCCC RNG" driver than individual "Amazon RNG", "NXP RNG" etc.!

TF-A even already includes some RNG drivers (e.g. RPi3) by the way..