On Thu, Nov 05, 2020 at 02:03:22PM +0000, Mark Rutland wrote: > On Thu, Nov 05, 2020 at 01:41:42PM +0000, Mark Brown wrote: > > 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. There's definitely a good argument for that, but OTOH it's possible the SMCCC implementation is doing something else (it'd be an interesting implementation decision but...). That said I don't really mind, I think my comment was more that if we're doing this the code should be explicit about what the intent is since right now it isn't obvious. Either a comment or having an explicit "what method are we choosing" thing. > 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? Yeah, I was wondering about this myself - it seems like a better fit for hwrng rather than the arch interfaces but that's not used until userspace comes up, the arch stuff is all expected to be quick. I suppose we could implement the SMCCC stuff for the early variants of the API you added so it gets used for bootstrapping purposes and then we rely on userspace keeping things topped up by fetching entropy through hwrng or otherwise but that feels confused so I have a hard time getting enthusiastic about it.
Attachment:
signature.asc
Description: PGP signature
_______________________________________________ kvmarm mailing list kvmarm@xxxxxxxxxxxxxxxxxxxxx https://lists.cs.columbia.edu/mailman/listinfo/kvmarm
