Messages in this thread | | | Date | Tue, 02 Jun 2020 14:02:47 +0100 | From | Marc Zyngier <> | Subject | Re: Security Random Number Generator support |
| |
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. -- Who you jivin' with that Cosmik Debris?
| |