From: Marc Zyngier <maz@kernel.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: "Julius Werner" <jwerner@google.com>,
"Ard Biesheuvel" <ardb@kernel.org>,
"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>,
linux-mediatek@lists.infradead.org,
lkml <linux-kernel@vger.kernel.org>,
wsd_upstream <wsd_upstream@mediatek.com>,
"Rob Herring" <robh+dt@kernel.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>,
mark.rutland@arm.com, Jose.Marinho@arm.com
Subject: Re: Security Random Number Generator support
Date: Wed, 03 Jun 2020 12:12:05 +0100 [thread overview]
Message-ID: <e56f0f8da7fdc836e073a37c9baeda77@kernel.org> (raw)
In-Reply-To: <1591170857.19414.5.camel@mtkswgap22>
On 2020-06-03 08:54, Neal Liu wrote:
> On Wed, 2020-06-03 at 08:40 +0100, Marc Zyngier wrote:
>> On 2020-06-03 08:29, Neal Liu wrote:
[...]
>> > 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.
>>
>> There is zero benefit in having a platform-dependent ID. It just
>> pointlessly increases complexity, and means we cannot use the RNG
>> before the firmware tables are available (yes, we need it that
>> early).
>>
>> M.
>
> Do you know which ARM expert could edict this standard?
> Or is there any chance that we can make one? And be reviewed by
> maintainers?
Sudeep already mentioned Jose's effort to offer a standard.
Hopefully he will *soon* be able to give us something that can be
implemented everywhere (firmware, kernel, but also hypervisors),
as the need exists across the whole stack.
M.
--
Jazz is not dead. It just smells funny...
WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: mark.rutland@arm.com,
"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>,
Jose.Marinho@arm.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 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: Wed, 03 Jun 2020 12:12:05 +0100 [thread overview]
Message-ID: <e56f0f8da7fdc836e073a37c9baeda77@kernel.org> (raw)
In-Reply-To: <1591170857.19414.5.camel@mtkswgap22>
On 2020-06-03 08:54, Neal Liu wrote:
> On Wed, 2020-06-03 at 08:40 +0100, Marc Zyngier wrote:
>> On 2020-06-03 08:29, Neal Liu wrote:
[...]
>> > 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.
>>
>> There is zero benefit in having a platform-dependent ID. It just
>> pointlessly increases complexity, and means we cannot use the RNG
>> before the firmware tables are available (yes, we need it that
>> early).
>>
>> M.
>
> Do you know which ARM expert could edict this standard?
> Or is there any chance that we can make one? And be reviewed by
> maintainers?
Sudeep already mentioned Jose's effort to offer a standard.
Hopefully he will *soon* be able to give us something that can be
implemented everywhere (firmware, kernel, but also hypervisors),
as the need exists across the whole stack.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
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@kernel.org>
To: Neal Liu <neal.liu@mediatek.com>
Cc: mark.rutland@arm.com,
"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>,
Jose.Marinho@arm.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 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: Wed, 03 Jun 2020 12:12:05 +0100 [thread overview]
Message-ID: <e56f0f8da7fdc836e073a37c9baeda77@kernel.org> (raw)
In-Reply-To: <1591170857.19414.5.camel@mtkswgap22>
On 2020-06-03 08:54, Neal Liu wrote:
> On Wed, 2020-06-03 at 08:40 +0100, Marc Zyngier wrote:
>> On 2020-06-03 08:29, Neal Liu wrote:
[...]
>> > 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.
>>
>> There is zero benefit in having a platform-dependent ID. It just
>> pointlessly increases complexity, and means we cannot use the RNG
>> before the firmware tables are available (yes, we need it that
>> early).
>>
>> M.
>
> Do you know which ARM expert could edict this standard?
> Or is there any chance that we can make one? And be reviewed by
> maintainers?
Sudeep already mentioned Jose's effort to offer a standard.
Hopefully he will *soon* be able to give us something that can be
implemented everywhere (firmware, kernel, but also hypervisors),
as the need exists across the whole stack.
M.
--
Jazz is not dead. It just smells funny...
_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel
next prev parent reply other threads:[~2020-06-03 11:12 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 [this message]
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=e56f0f8da7fdc836e073a37c9baeda77@kernel.org \
--to=maz@kernel.org \
--cc=Crystal.Guo@mediatek.com \
--cc=Jose.Marinho@arm.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=mark.rutland@arm.com \
--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.