All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@misterjones.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: Neal Liu <neal.liu@mediatek.com>,
	"open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS" 
	<devicetree@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sean Wang <sean.wang@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	wsd_upstream@mediatek.com, Rob Herring <robh+dt@kernel.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>,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Security Random Number Generator support
Date: Tue, 02 Jun 2020 14:02:47 +0100	[thread overview]
Message-ID: <85dfc0142d3879d50c0ba18bcc71e199@misterjones.org> (raw)
In-Reply-To: <CAMj1kXHjAdk5=-uSh_=S9j5cz42zr3h6t+YYGy+obevuQDp0fg@mail.gmail.com>

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?

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@misterjones.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sean Wang <sean.wang@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	wsd_upstream@mediatek.com, Crystal Guo <Crystal.Guo@mediatek.com>,
	Rob Herring <robh+dt@kernel.org>,
	Neal Liu <neal.liu@mediatek.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Matt Mackall <mpm@selenic.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-mediatek@lists.infradead.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Security Random Number Generator support
Date: Tue, 02 Jun 2020 14:02:47 +0100	[thread overview]
Message-ID: <85dfc0142d3879d50c0ba18bcc71e199@misterjones.org> (raw)
In-Reply-To: <CAMj1kXHjAdk5=-uSh_=S9j5cz42zr3h6t+YYGy+obevuQDp0fg@mail.gmail.com>

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?

_______________________________________________
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: Marc Zyngier <maz@misterjones.org>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: "open list:OPEN FIRMWARE AND FLATTENED DEVICE TREE BINDINGS"
	<devicetree@vger.kernel.org>,
	Herbert Xu <herbert@gondor.apana.org.au>,
	Arnd Bergmann <arnd@arndb.de>,
	Greg Kroah-Hartman <gregkh@linuxfoundation.org>,
	Sean Wang <sean.wang@kernel.org>,
	lkml <linux-kernel@vger.kernel.org>,
	wsd_upstream@mediatek.com, Crystal Guo <Crystal.Guo@mediatek.com>,
	Rob Herring <robh+dt@kernel.org>,
	Neal Liu <neal.liu@mediatek.com>,
	Linux Crypto Mailing List <linux-crypto@vger.kernel.org>,
	Matt Mackall <mpm@selenic.com>,
	Matthias Brugger <matthias.bgg@gmail.com>,
	linux-mediatek@lists.infradead.org,
	Linux ARM <linux-arm-kernel@lists.infradead.org>
Subject: Re: Security Random Number Generator support
Date: Tue, 02 Jun 2020 14:02:47 +0100	[thread overview]
Message-ID: <85dfc0142d3879d50c0ba18bcc71e199@misterjones.org> (raw)
In-Reply-To: <CAMj1kXHjAdk5=-uSh_=S9j5cz42zr3h6t+YYGy+obevuQDp0fg@mail.gmail.com>

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?

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

  reply	other threads:[~2020-06-02 13:33 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 [this message]
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
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=85dfc0142d3879d50c0ba18bcc71e199@misterjones.org \
    --to=maz@misterjones.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=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=matthias.bgg@gmail.com \
    --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.