Question on get random long worse in VM than on host

[Ard Biesheuvel]

On Tue, 3 Sept 2024 at 03:39, Tangnianyao <tangnianyao at huawei.com> wrote:
>
>
>
> 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?
>

There are other, non-architected ways too to get entropy and/or
randomness. There are many hardware random number generator
peripherals that the OS can drive directly, and there are vendor
specific EL3 services too that a system might use.

RNDR/RNDRRS does not exist yet in practical terms - there are very few
SOCs that actually implement that used in the field.

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

I don't understand this question. How the host obtains its entropy
and/or randomness and how the guest does it are completely separate
concerns.