All of lore.kernel.org
 help / color / mirror / Atom feed
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Neal Liu" <neal.liu@mediatek.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Will Deacon" <will@kernel.org>, "Lars Persson" <lists@bofh.nu>,
	"Mark Rutland" <mark.rutland@arm.com>,
	DTML <devicetree@vger.kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	"Sean Wang" <sean.wang@kernel.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Crystal Guo (郭晶)" <Crystal.Guo@mediatek.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
Date: Mon, 2 Dec 2019 19:11:46 +0000	[thread overview]
Message-ID: <20191202191146.79e6368c@why> (raw)
In-Reply-To: <CAKv+Gu_um7eRYXbieW7ogDX5mmZaxP7JQBJM9CajK+6CsO5RgQ@mail.gmail.com>

On Mon, 2 Dec 2019 16:12:09 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> (adding some more arm64 folks)
> 
> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
> >
> > On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:  
> > > Hi Neal,
> > >
> > > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:  
> > > >
> > > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > > > entropy sources is not accessible from normal world (linux) and
> > > > rather accessible from secure world (ATF/TEE) only. This driver aims
> > > > to provide a generic interface to ATF rng service.
> > > >  
> > >
> > > I am working on several SoCs that also will need this kind of driver
> > > to get entropy from Arm trusted firmware.
> > > If you intend to make this a generic interface, please clean up the
> > > references to MediaTek and give it a more generic name. For example
> > > "Arm Trusted Firmware random number driver".
> > >
> > > It will also be helpful if the SMC call number is configurable.
> > >
> > > - Lars  
> >
> > Yes, I'm trying to make this to a generic interface. I'll try to make
> > HW/platform related dependency to be configurable and let it more
> > generic.
> > Thanks for your suggestion.
> >  
> 
> I don't think it makes sense for each arm64 platform to expose an
> entropy source via SMC calls in a slightly different way, and model it
> as a h/w driver. Instead, we should try to standardize this, and
> perhaps expose it via the architectural helpers that already exist
> (get_random_seed_long() and friends), so they get plugged into the
> kernel random pool driver directly.

Absolutely. I'd love to see a standard, ARM-specified, virtualizable
RNG that is abstracted from the HW.

> Note that in addition to drivers based on vendor SMC calls, we already
> have a RNG h/w driver based on OP-TEE as well, where the driver
> attaches to a standardized trusted OS interface identified by a UUID,
> and which also gets invoked via SMC calls into secure firmware.

... and probably an unhealthy number of hypervisor-specific hacks that
do the same thing. The sooner we plug this, the better.

Thanks,

	M.
-- 
Jazz is not dead. It just smells funny...

WARNING: multiple messages have this Message-ID (diff)
From: Marc Zyngier <maz@kernel.org>
To: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	DTML <devicetree@vger.kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Sean Wang" <sean.wang@kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Neal Liu" <neal.liu@mediatek.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Crystal Guo (郭晶)" <Crystal.Guo@mediatek.com>,
	"Will Deacon" <will@kernel.org>, "Lars Persson" <lists@bofh.nu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
Date: Mon, 2 Dec 2019 19:11:46 +0000	[thread overview]
Message-ID: <20191202191146.79e6368c@why> (raw)
In-Reply-To: <CAKv+Gu_um7eRYXbieW7ogDX5mmZaxP7JQBJM9CajK+6CsO5RgQ@mail.gmail.com>

On Mon, 2 Dec 2019 16:12:09 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> (adding some more arm64 folks)
> 
> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
> >
> > On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:  
> > > Hi Neal,
> > >
> > > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:  
> > > >
> > > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > > > entropy sources is not accessible from normal world (linux) and
> > > > rather accessible from secure world (ATF/TEE) only. This driver aims
> > > > to provide a generic interface to ATF rng service.
> > > >  
> > >
> > > I am working on several SoCs that also will need this kind of driver
> > > to get entropy from Arm trusted firmware.
> > > If you intend to make this a generic interface, please clean up the
> > > references to MediaTek and give it a more generic name. For example
> > > "Arm Trusted Firmware random number driver".
> > >
> > > It will also be helpful if the SMC call number is configurable.
> > >
> > > - Lars  
> >
> > Yes, I'm trying to make this to a generic interface. I'll try to make
> > HW/platform related dependency to be configurable and let it more
> > generic.
> > Thanks for your suggestion.
> >  
> 
> I don't think it makes sense for each arm64 platform to expose an
> entropy source via SMC calls in a slightly different way, and model it
> as a h/w driver. Instead, we should try to standardize this, and
> perhaps expose it via the architectural helpers that already exist
> (get_random_seed_long() and friends), so they get plugged into the
> kernel random pool driver directly.

Absolutely. I'd love to see a standard, ARM-specified, virtualizable
RNG that is abstracted from the HW.

> Note that in addition to drivers based on vendor SMC calls, we already
> have a RNG h/w driver based on OP-TEE as well, where the driver
> attaches to a standardized trusted OS interface identified by a UUID,
> and which also gets invoked via SMC calls into secure firmware.

... and probably an unhealthy number of hypervisor-specific hacks that
do the same thing. The sooner we plug this, the better.

Thanks,

	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: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: "Mark Rutland" <mark.rutland@arm.com>,
	DTML <devicetree@vger.kernel.org>,
	"Herbert Xu" <herbert@gondor.apana.org.au>,
	wsd_upstream <wsd_upstream@mediatek.com>,
	"Catalin Marinas" <catalin.marinas@arm.com>,
	"Sean Wang" <sean.wang@kernel.org>,
	"linux-mediatek@lists.infradead.org"
	<linux-mediatek@lists.infradead.org>,
	"Linux Kernel Mailing List" <linux-kernel@vger.kernel.org>,
	"Rob Herring" <robh+dt@kernel.org>,
	"Neal Liu" <neal.liu@mediatek.com>,
	"linux-crypto@vger.kernel.org" <linux-crypto@vger.kernel.org>,
	"Matt Mackall" <mpm@selenic.com>,
	"Matthias Brugger" <matthias.bgg@gmail.com>,
	"Crystal Guo (郭晶)" <Crystal.Guo@mediatek.com>,
	"Will Deacon" <will@kernel.org>, "Lars Persson" <lists@bofh.nu>,
	"linux-arm-kernel@lists.infradead.org"
	<linux-arm-kernel@lists.infradead.org>
Subject: Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver
Date: Mon, 2 Dec 2019 19:11:46 +0000	[thread overview]
Message-ID: <20191202191146.79e6368c@why> (raw)
In-Reply-To: <CAKv+Gu_um7eRYXbieW7ogDX5mmZaxP7JQBJM9CajK+6CsO5RgQ@mail.gmail.com>

On Mon, 2 Dec 2019 16:12:09 +0000
Ard Biesheuvel <ard.biesheuvel@linaro.org> wrote:

> (adding some more arm64 folks)
> 
> On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@mediatek.com> wrote:
> >
> > On Fri, 2019-11-29 at 18:02 +0800, Lars Persson wrote:  
> > > Hi Neal,
> > >
> > > On Wed, Nov 27, 2019 at 3:23 PM Neal Liu <neal.liu@mediatek.com> wrote:  
> > > >
> > > > For MediaTek SoCs on ARMv8 with TrustZone enabled, peripherals like
> > > > entropy sources is not accessible from normal world (linux) and
> > > > rather accessible from secure world (ATF/TEE) only. This driver aims
> > > > to provide a generic interface to ATF rng service.
> > > >  
> > >
> > > I am working on several SoCs that also will need this kind of driver
> > > to get entropy from Arm trusted firmware.
> > > If you intend to make this a generic interface, please clean up the
> > > references to MediaTek and give it a more generic name. For example
> > > "Arm Trusted Firmware random number driver".
> > >
> > > It will also be helpful if the SMC call number is configurable.
> > >
> > > - Lars  
> >
> > Yes, I'm trying to make this to a generic interface. I'll try to make
> > HW/platform related dependency to be configurable and let it more
> > generic.
> > Thanks for your suggestion.
> >  
> 
> I don't think it makes sense for each arm64 platform to expose an
> entropy source via SMC calls in a slightly different way, and model it
> as a h/w driver. Instead, we should try to standardize this, and
> perhaps expose it via the architectural helpers that already exist
> (get_random_seed_long() and friends), so they get plugged into the
> kernel random pool driver directly.

Absolutely. I'd love to see a standard, ARM-specified, virtualizable
RNG that is abstracted from the HW.

> Note that in addition to drivers based on vendor SMC calls, we already
> have a RNG h/w driver based on OP-TEE as well, where the driver
> attaches to a standardized trusted OS interface identified by a UUID,
> and which also gets invoked via SMC calls into secure firmware.

... and probably an unhealthy number of hypervisor-specific hacks that
do the same thing. The sooner we plug this, the better.

Thanks,

	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

  reply	other threads:[~2019-12-02 19:12 UTC|newest]

Thread overview: 54+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-11-27 14:22 [PATCH v5 0/3] MediaTek Security random number generator support Neal Liu
2019-11-27 14:22 ` Neal Liu
2019-11-27 14:22 ` Neal Liu
2019-11-27 14:22 ` [PATCH v5 1/3] soc: mediatek: add SMC fid table for SIP interface Neal Liu
2019-11-27 14:22   ` Neal Liu
2019-11-27 14:22   ` Neal Liu
2019-11-27 14:22 ` [PATCH v5 2/3] dt-bindings: rng: add bindings for MediaTek ARMv8 SoCs Neal Liu
2019-11-27 14:22   ` Neal Liu
2019-11-27 14:22   ` Neal Liu
2019-11-27 14:22 ` [PATCH v5 3/3] hwrng: add mtk-sec-rng driver Neal Liu
2019-11-27 14:22   ` Neal Liu
2019-11-27 14:22   ` Neal Liu
2019-11-27 15:03   ` Ard Biesheuvel
2019-11-27 15:03     ` Ard Biesheuvel
2019-11-27 15:03     ` Ard Biesheuvel
2019-11-28 15:02     ` Neal Liu
2019-11-28 15:02       ` Neal Liu
2019-11-28 15:02       ` Neal Liu
2019-11-29 10:02   ` Lars Persson
2019-11-29 10:02     ` Lars Persson
2019-11-29 10:02     ` Lars Persson
2019-11-29 11:30     ` Neal Liu
2019-11-29 11:30       ` Neal Liu
2019-11-29 11:30       ` Neal Liu
2019-12-02 16:12       ` Ard Biesheuvel
2019-12-02 16:12         ` Ard Biesheuvel
2019-12-02 16:12         ` Ard Biesheuvel
2019-12-02 19:11         ` Marc Zyngier [this message]
2019-12-02 19:11           ` Marc Zyngier
2019-12-02 19:11           ` Marc Zyngier
2019-12-03  4:16           ` Florian Fainelli
2019-12-03  4:16             ` Florian Fainelli
2019-12-03  4:16             ` Florian Fainelli
2019-12-03 11:17             ` Marc Zyngier
2019-12-03 11:17               ` Marc Zyngier
2019-12-03 11:17               ` Marc Zyngier
2019-12-12  5:13               ` Neal Liu
2019-12-12  5:13                 ` Neal Liu
2019-12-12  5:13                 ` Neal Liu
2019-12-12 11:45                 ` Marc Zyngier
2019-12-12 11:45                   ` Marc Zyngier
2019-12-12 11:45                   ` Marc Zyngier
2019-12-12 14:03                   ` Ard Biesheuvel
2019-12-12 14:03                     ` Ard Biesheuvel
2019-12-12 14:03                     ` Ard Biesheuvel
2019-12-12 14:30                     ` Marc Zyngier
2019-12-12 14:30                       ` Marc Zyngier
2019-12-12 14:30                       ` Marc Zyngier
2019-12-03 10:17           ` Will Deacon
2019-12-03 10:17             ` Will Deacon
2019-12-03 10:17             ` Will Deacon
2019-12-12 14:43         ` Sudeep Holla
2019-12-12 14:43           ` Sudeep Holla
2019-12-12 14:43           ` Sudeep Holla

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=20191202191146.79e6368c@why \
    --to=maz@kernel.org \
    --cc=Crystal.Guo@mediatek.com \
    --cc=ard.biesheuvel@linaro.org \
    --cc=catalin.marinas@arm.com \
    --cc=devicetree@vger.kernel.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=lists@bofh.nu \
    --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=will@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.