Messages in this thread | | | Date | Wed, 03 Jun 2020 08:40:58 +0100 | From | Marc Zyngier <> | Subject | Re: Security Random Number Generator support |
| |
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@mediatek.com> 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. -- Jazz is not dead. It just smells funny...
| |