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...
