Re: [PATCH v5 3/3] hwrng: add mtk-sec-rng driver

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 2019-12-03 04:16, Florian Fainelli wrote:
On 12/2/2019 11:11 AM, Marc Zyngier wrote:
On Mon, 2 Dec 2019 16:12:09 +0000
Ard Biesheuvel <ard.biesheuvel@xxxxxxxxxx> wrote:

(adding some more arm64 folks)

On Fri, 29 Nov 2019 at 11:30, Neal Liu <neal.liu@xxxxxxxxxxxx> 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@xxxxxxxxxxxx> 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.

Do you think we could use virtio-rng on top of a modified virtio-mmio
which instead of being backed by a hardware mailbox, could use hvc/smc
calls to signal writes to shared memory and get notifications via an
interrupt? This would also open up the doors to other virtio uses cases beyond just RNG (e.g.: console, block devices?). If this is completely
stupid, then please disregard this comment.

The problem with a virtio device is that it is a ... device. What we want is to be able to have access to an entropy source extremely early in the
kernel life, and devices tend to be available pretty late in the game.
This means we cannot plug them in the architectural helpers that Ard
mentions above.

What you're suggesting looks more like a new kind of virtio transport,
which is interesting, in a remarkably twisted way... ;-)

Thanks,

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



[Index of Archives]     [Kernel]     [Gnu Classpath]     [Gnu Crypto]     [DM Crypt]     [Netfilter]     [Bugtraq]

  Powered by Linux