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: <20200603093416.GY1551@shell.armlinux.org.uk>
Date:   Wed, 3 Jun 2020 10:34:16 +0100
From:   Russell King - ARM Linux admin <linux@...linux.org.uk>
To:     Marc Zyngier <maz@...nel.org>
Cc:     Neal Liu <neal.liu@...iatek.com>,
        "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>,
        lkml <linux-kernel@...r.kernel.org>,
        wsd_upstream <wsd_upstream@...iatek.com>,
        Rob Herring <robh+dt@...nel.org>,
        linux-mediatek@...ts.infradead.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 Wed, Jun 03, 2020 at 08:40:58AM +0100, Marc Zyngier wrote:
> 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@...iatek.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.

This sounds all too familiar.

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.

Then OMAP came along with its SMC interfaces, and so did the pain of
not having a standardised way to configure the L2C when Linux was
running in the non-secure world, resulting in stuff like l2c_configure
etc, where each and every implementation has to supply a function to
call its platform specific SMC interfaces to configure a piece of
hardware common across many different platforms.

ARM have seemed reluctant to standardise on stuff like this, so
unless someone pushes hard for it from inside ARM, I doubt it will
ever happen.

-- 
RMK's Patch system: https://www.armlinux.org.uk/developer/patches/
FTTC for 0.8m (est. 1762m) line in suburbia: sync at 13.1Mbps down 424kbps up