[PATCH v2 4/5] arm64: Add support for SMCCC TRNG entropy source

[André Przywara]

On 05/11/2020 14:03, Mark Rutland wrote:
> On Thu, Nov 05, 2020 at 01:41:42PM +0000, Mark Brown wrote:
>> On Thu, Nov 05, 2020 at 12:56:55PM +0000, Andre Przywara wrote:
>>
>>>  static inline bool __must_check arch_get_random_seed_int(unsigned int *v)
>>>  {
>>> +	struct arm_smccc_res res;
>>>  	unsigned long val;
>>> -	bool ok = arch_get_random_seed_long(&val);
>>>  
>>> -	*v = val;
>>> -	return ok;
>>> +	if (cpus_have_const_cap(ARM64_HAS_RNG)) {
>>> +		if (arch_get_random_seed_long(&val)) {
>>> +			*v = val;
>>> +			return true;
>>> +		}
>>> +		return false;
>>> +	}
>>
>> It isn't obvious to me why we don't fall through to trying the SMCCC
>> TRNG here if for some reason the v8.5-RNG didn't give us something.
>> Definitely an obscure possibility but still...
> 
> I think it's better to assume that if we have a HW RNG and it's not
> giving us entropy, it's not worthwhile trapping to the host, which might
> encounter the exact same issue.
> 
> I'd rather we have one RNG source that we trust works, and use that
> exclusively.
> 
> That said, I'm not sure it's great to plumb this under the
> arch_get_random*() interfaces, e.g. given this measn that
> add_interrupt_randomness() will end up trapping to the host all the time
> when it calls arch_get_random_seed_long().
> 
> Is there an existing interface for "slow" runtime entropy that we can
> plumb this into instead?

There is the framework implementing /dev/hwrng, and in fact I started
with a driver for that (have that in some working state).
But this is only available somewhat late in the game (after drivers get
initialised), and Ard mentioned that one advantage of the firmware i/f
is (somewhat) early availability. Now for SMCCC we need firmware tables
(for the conduit), so it's not too early either.

If too frequent firmware traps are a concern, we could always request
the maximum 192 bits, and store them. That would avoid 2/3 of the
current traps.

Cheers,
Andre