[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAFA6WYNqWmhiz=wvCTt1ubMtrhf+RtFSC2GiQQeteEbmrF1EnQ@mail.gmail.com>
Date: Mon, 8 Jun 2020 13:19:16 +0530
From: Sumit Garg <sumit.garg@...aro.org>
To: Neal Liu <neal.liu@...iatek.com>
Cc: Russell King - ARM Linux admin <linux@...linux.org.uk>,
"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
<devicetree@...r.kernel.org>, Julius Werner <jwerner@...gle.com>,
Herbert Xu <herbert@...dor.apana.org.au>,
Arnd Bergmann <arnd@...db.de>, Marc Zyngier <maz@...nel.org>,
Matt Mackall <mpm@...enic.com>,
Sean Wang <sean.wang@...nel.org>,
lkml <linux-kernel@...r.kernel.org>,
wsd_upstream <wsd_upstream@...iatek.com>,
Rob Herring <robh+dt@...nel.org>,
"linux-mediatek@...ts.infradead.org"
<linux-mediatek@...ts.infradead.org>,
Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
Matthias Brugger <matthias.bgg@...il.com>,
Crystal Guo (郭晶) <Crystal.Guo@...iatek.com>,
Ard Biesheuvel <ardb@...nel.org>,
Linux ARM <linux-arm-kernel@...ts.infradead.org>
Subject: Re: Security Random Number Generator support
Hi Neal,
On Fri, 5 Jun 2020 at 14:40, Neal Liu <neal.liu@...iatek.com> wrote:
>
> On Fri, 2020-06-05 at 09:09 +0100, Russell King - ARM Linux admin wrote:
> > On Fri, Jun 05, 2020 at 03:19:03PM +0800, Neal Liu wrote:
> > > On Wed, 2020-06-03 at 17:34 +0800, Russell King - ARM Linux admin wrote:
> > > > This kind of thing is something that ARM have seems to shy away from
> > > > doing - it's a point I brought up many years ago when the whole
> > > > trustzone thing first appeared with its SMC call. Those around the
> > > > conference table were not interested - ARM seemed to prefer every
> > > > vendor to do off and do their own thing with the SMC interface.
> > >
> > > Does that mean it make sense to model a sec-rng driver, and get each
> > > vendor's SMC function id by DT node?
> >
> > _If_ vendors have already gone off and decided to use different SMC
> > function IDs for this, while keeping the rest of the SMC interface
> > the same, then the choice has already been made.
> >
> > I know on 32-bit that some of the secure world implementations can't
> > be changed; they're burnt into the ROM. I believe on 64-bit that isn't
> > the case, which makes it easier to standardise.
> >
> > Do you have visibility of how this SMC is implemented in the secure
> > side? Is it in ATF, and is it done as a vendor hack or is there an
> > element of generic implementation to it? Has it been submitted
> > upstream to the main ATF repository?
> >
>
> Take MediaTek as an example, some SoCs are implemented in ATF, some of
> them are implemented in TEE.
In case your TEE implementation is derived from OP-TEE, then I will
suggest you to re-use OP-TEE based RNG driver [1]. With that, you just
need to implement an OP-TEE based pseudo trusted application (similar
to this [2]) specific to your platform and need to extend driver UUID
config table [3] with UUID of your platform specific pseudo TA. This
way you can avoid using hardcoded DT based SMC approach and rather use
auto RNG device detection provided by TEE bus.
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random/optee-rng.c
[2] https://github.com/OP-TEE/optee_os/blob/master/core/arch/arm/plat-synquacer/rng_pta.c
[3] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/drivers/char/hw_random/optee-rng.c#n273
-Sumit
> We have no plan to make generic
> implementation in "secure world".
>
> Due to there must have different implementation in secure world for
> vendors, we plan to provide a generic SMC interface in secure rng kernel
> driver for more flexibility.
>
> Vendors can decide which "secure world" they want (HYP/ATF/TEE) by
> different smc/hvc and different SMC function IDs in DT node.
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@...ts.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
Powered by blists - more mailing lists