linux-kernel - Re: Security Random Number Generator support

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <1591347582.21704.9.camel@mtkswgap22>
Date:   Fri, 5 Jun 2020 16:59:42 +0800
From:   Neal Liu <neal.liu@...iatek.com>
To:     Russell King - ARM Linux admin <linux@...linux.org.uk>
CC:     Marc Zyngier <maz@...nel.org>,
        "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>,
        Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        Sean Wang <sean.wang@...nel.org>,
        "linux-mediatek@...ts.infradead.org" 
        <linux-mediatek@...ts.infradead.org>,
        lkml <linux-kernel@...r.kernel.org>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        Rob Herring <robh+dt@...nel.org>,
        Linux Crypto Mailing List <linux-crypto@...r.kernel.org>,
        Matt Mackall <mpm@...enic.com>,
        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

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. 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.