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.
