On Wed, 2020-06-03 at 08:40 +0100, Marc Zyngier wrote: > On 2020-06-03 08:29, Neal Liu wrote: > > On Tue, 2020-06-02 at 21:02 +0800, Marc Zyngier wrote: > >> On 2020-06-02 13:14, Ard Biesheuvel wrote: > >> > On Tue, 2 Jun 2020 at 10:15, Neal Liu <neal.liu@xxxxxxxxxxxx> wrote: > >> >> > >> >> These patch series introduce a security random number generator > >> >> which provides a generic interface to get hardware rnd from Secure > >> >> state. The Secure state can be Arm Trusted Firmware(ATF), Trusted > >> >> Execution Environment(TEE), or even EL2 hypervisor. > >> >> > >> >> Patch #1..2 adds sec-rng kernel driver for Trustzone based SoCs. > >> >> For security awareness SoCs on ARMv8 with TrustZone enabled, > >> >> peripherals like entropy sources is not accessible from normal world > >> >> (linux) and rather accessible from secure world (HYP/ATF/TEE) only. > >> >> This driver aims to provide a generic interface to Arm Trusted > >> >> Firmware or Hypervisor rng service. > >> >> > >> >> > >> >> changes since v1: > >> >> - rename mt67xx-rng to mtk-sec-rng since all MediaTek ARMv8 SoCs can > >> >> reuse > >> >> this driver. > >> >> - refine coding style and unnecessary check. > >> >> > >> >> changes since v2: > >> >> - remove unused comments. > >> >> - remove redundant variable. > >> >> > >> >> changes since v3: > >> >> - add dt-bindings for MediaTek rng with TrustZone enabled. > >> >> - revise HWRNG SMC call fid. > >> >> > >> >> changes since v4: > >> >> - move bindings to the arm/firmware directory. > >> >> - revise driver init flow to check more property. > >> >> > >> >> changes since v5: > >> >> - refactor to more generic security rng driver which > >> >> is not platform specific. > >> >> > >> >> *** BLURB HERE *** > >> >> > >> >> Neal Liu (2): > >> >> dt-bindings: rng: add bindings for sec-rng > >> >> hwrng: add sec-rng driver > >> >> > >> > > >> > There is no reason to model a SMC call as a driver, and represent it > >> > via a DT node like this. > >> > >> +1. > >> > >> > It would be much better if this SMC interface is made truly generic, > >> > and wired into the arch_get_random() interface, which can be used much > >> > earlier. > >> > >> Wasn't there a plan to standardize a SMC call to rule them all? > >> > >> M. > > > > Could you give us a hint how to make this SMC interface more generic in > > addition to my approach? > > There is no (easy) way to get platform-independent SMC function ID, > > which is why we encode it into device tree, and provide a generic > > driver. In this way, different devices can be mapped and then get > > different function ID internally. > > The idea is simply to have *one* single ID that caters for all > implementations, just like we did for PSCI at the time. This > requires ARM to edict a standard, which is what I was referring > to above. > > There is zero benefit in having a platform-dependent ID. It just > pointlessly increases complexity, and means we cannot use the RNG > before the firmware tables are available (yes, we need it that > early). > > M. Do you know which ARM expert could edict this standard? Or is there any chance that we can make one? And be reviewed by maintainers?
