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.
