All of lore.kernel.org
 help / color / mirror / Atom feed
From: Sumit Garg <sumit.garg@linaro.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: "Russell King - ARM Linux admin" <linux@armlinux.org.uk>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"Julius Werner" <jwerner@google.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Arnd Bergmann" <arnd@arndb.de>, "Marc Zyngier" <maz@kernel.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Sean Wang" <sean.wang@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	"Rob Herring" <robh+dt@kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Crystal Guo (郭晶)" <Crystal.Guo@mediatek.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: Security Random Number Generator support
Date: Mon, 8 Jun 2020 13:19:16 +0530	[thread overview]
Message-ID: <CAFA6WYNqWmhiz=wvCTt1ubMtrhf+RtFSC2GiQQeteEbmrF1EnQ@mail.gmail.com> (raw)
In-Reply-To: <1591347582.21704.9.camel@mtkswgap22>

Hi Neal,

On Fri, 5 Jun 2020 at 14:40, Neal Liu <neal.liu@mediatek.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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

WARNING: multiple messages have this Message-ID (diff)
From: Sumit Garg <sumit.garg@linaro.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"Julius Werner" <jwerner@google.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Marc Zyngier" <maz@kernel.org>,
	"Sean Wang" <sean.wang@kernel.org>,
	"Russell King - ARM Linux admin" <linux@armlinux.org.uk>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Crystal Guo (郭晶)" <Crystal.Guo@mediatek.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: Security Random Number Generator support
Date: Mon, 8 Jun 2020 13:19:16 +0530	[thread overview]
Message-ID: <CAFA6WYNqWmhiz=wvCTt1ubMtrhf+RtFSC2GiQQeteEbmrF1EnQ@mail.gmail.com> (raw)
In-Reply-To: <1591347582.21704.9.camel@mtkswgap22>

Hi Neal,

On Fri, 5 Jun 2020 at 14:40, Neal Liu <neal.liu@mediatek.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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
Linux-mediatek mailing list
Linux-mediatek@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-mediatek

WARNING: multiple messages have this Message-ID (diff)
From: Sumit Garg <sumit.garg@linaro.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	"Julius Werner" <jwerner@google.com>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	"Arnd Bergmann" <arnd@arndb.de>,
	"Greg Kroah-Hartman" <gregkh@linuxfoundation.org>,
	"Marc Zyngier" <maz@kernel.org>,
	"Sean Wang" <sean.wang@kernel.org>,
	"Russell King - ARM Linux admin" <linux@armlinux.org.uk>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	lkml <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Linux Crypto Mailing List" <linux-crypto@vger.kernel.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Crystal Guo (郭晶)" <Crystal.Guo@mediatek.com>,
	"Ard Biesheuvel" <ardb@kernel.org>,
	"Linux ARM" <linux-arm-kernel@lists.infradead.org>
Subject: Re: Security Random Number Generator support
Date: Mon, 8 Jun 2020 13:19:16 +0530	[thread overview]
Message-ID: <CAFA6WYNqWmhiz=wvCTt1ubMtrhf+RtFSC2GiQQeteEbmrF1EnQ@mail.gmail.com> (raw)
In-Reply-To: <1591347582.21704.9.camel@mtkswgap22>

Hi Neal,

On Fri, 5 Jun 2020 at 14:40, Neal Liu <neal.liu@mediatek.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@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  parent reply	other threads:[~2020-06-08  7:49 UTC|newest]

Thread overview: 57+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-06-02  8:14 Security Random Number Generator support Neal Liu
2020-06-02  8:14 ` Neal Liu
2020-06-02  8:14 ` Neal Liu
2020-06-02  8:14 ` [PATCH v6 1/2] dt-bindings: rng: add bindings for sec-rng Neal Liu
2020-06-02  8:14   ` Neal Liu
2020-06-02  8:14   ` Neal Liu
2020-06-02  8:14 ` [PATCH v6 2/2] hwrng: add sec-rng driver Neal Liu
2020-06-02  8:14   ` Neal Liu
2020-06-02  8:14   ` Neal Liu
2020-06-02 10:38   ` Greg Kroah-Hartman
2020-06-02 10:38     ` Greg Kroah-Hartman
2020-06-02 10:38     ` Greg Kroah-Hartman
2020-06-02 12:14 ` Security Random Number Generator support Ard Biesheuvel
2020-06-02 12:14   ` Ard Biesheuvel
2020-06-02 12:14   ` Ard Biesheuvel
2020-06-02 13:02   ` Marc Zyngier
2020-06-02 13:02     ` Marc Zyngier
2020-06-02 13:02     ` Marc Zyngier
2020-06-03  7:29     ` Neal Liu
2020-06-03  7:29       ` Neal Liu
2020-06-03  7:29       ` Neal Liu
2020-06-03  7:40       ` Marc Zyngier
2020-06-03  7:40         ` Marc Zyngier
2020-06-03  7:40         ` Marc Zyngier
2020-06-03  7:54         ` Neal Liu
2020-06-03  7:54           ` Neal Liu
2020-06-03  7:54           ` Neal Liu
2020-06-03  9:48           ` Sudeep Holla
2020-06-03  9:48             ` Sudeep Holla
2020-06-03  9:48             ` Sudeep Holla
2020-06-03 11:12           ` Marc Zyngier
2020-06-03 11:12             ` Marc Zyngier
2020-06-03 11:12             ` Marc Zyngier
2020-06-18  9:50           ` Marc Zyngier
2020-06-18  9:50             ` Marc Zyngier
2020-06-18  9:50             ` Marc Zyngier
2020-06-19  1:47             ` Neal Liu
2020-06-19  1:47               ` Neal Liu
2020-06-19  1:47               ` Neal Liu
2020-06-03  9:34         ` Russell King - ARM Linux admin
2020-06-03  9:34           ` Russell King - ARM Linux admin
2020-06-03  9:34           ` Russell King - ARM Linux admin
2020-06-05  7:19           ` Neal Liu
2020-06-05  7:19             ` Neal Liu
2020-06-05  7:19             ` Neal Liu
2020-06-05  8:09             ` Russell King - ARM Linux admin
2020-06-05  8:09               ` Russell King - ARM Linux admin
2020-06-05  8:09               ` Russell King - ARM Linux admin
2020-06-05  8:59               ` Neal Liu
2020-06-05  8:59                 ` Neal Liu
2020-06-05  8:59                 ` Neal Liu
2020-06-05  9:27                 ` Russell King - ARM Linux admin
2020-06-05  9:27                   ` Russell King - ARM Linux admin
2020-06-05  9:27                   ` Russell King - ARM Linux admin
2020-06-08  7:49                 ` Sumit Garg [this message]
2020-06-08  7:49                   ` Sumit Garg
2020-06-08  7:49                   ` Sumit Garg

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAFA6WYNqWmhiz=wvCTt1ubMtrhf+RtFSC2GiQQeteEbmrF1EnQ@mail.gmail.com' \
    --to=sumit.garg@linaro.org \
    --cc=Crystal.Guo@mediatek.com \
    --cc=ardb@kernel.org \
    --cc=arnd@arndb.de \
    --cc=devicetree@vger.kernel.org \
    --cc=gregkh@linuxfoundation.org \
    --cc=herbert@gondor.apana.org.au \
    --cc=jwerner@google.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-crypto@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mediatek@lists.infradead.org \
    --cc=linux@armlinux.org.uk \
    --cc=matthias.bgg@gmail.com \
    --cc=maz@kernel.org \
    --cc=mpm@selenic.com \
    --cc=neal.liu@mediatek.com \
    --cc=robh+dt@kernel.org \
    --cc=sean.wang@kernel.org \
    --cc=wsd_upstream@mediatek.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.