Question on get random long worse in VM than on host

[Tangnianyao]

On 9/3/2024 5:26, Ard Biesheuvel wrote:
> On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz at kernel.org> wrote:
>> On Sat, 31 Aug 2024 08:56:23 +0100,
>> Ard Biesheuvel <ardb at kernel.org> wrote:
>>> As for RNDR/RNDRRS vs TRNG: the former is not a raw entropy source, it
>>> is a DRBG (or CSPRNG) which provides cryptographically secure random
>>> numbers whose security strength is limited by the size of the seed.
>>> TRNG does not have this limitation in principle, although non-p KVM
>>> happily seeds it from the kernel's entropy pool, which has the same
>>> limitation in practice.
>> Is that something we should address? I assume that this has an impact
>> on the quality of the provided random numbers?
>>
> To be honest, I personally find the distinction rather theoretical - I
> think it will be mostly the FIPS fetishists who may object to the
> seeding of a DRBG of security strength 'n' from the kernel entropy
> pool without proving that the sample has 'n' bits of entropy.
>
> For pKVM, the concern was that the untrusted host could observe and
> manipulate the entropy and therefore the protected guest's entropy
> source, which is why the hypervisor relays TRNG SMCCC calls directly
> to the secure firmware in that case. The quality of the entropy was
> never a concern here.
>
> .
>

Thank you for reply.

In case that EL3 firmware not support SMCCC TRNG, host and guest can only
get randomness from DRBG-based RNDRRS, right?

In this case, guest get DRBG-based randomness via HVC and host, but the
randomness returned by host kvm is not really backed by EL3 SMCCC TRNG,
and actually get from DRBG-based RNDRRS.
Is this hvc process is redundancy?

Thanks.