Re: Question on get random long worse in VM than on host

[Marc Zyngier]

On Thu, 05 Sep 2024 04:12:42 +0100,
Tangnianyao <tangnianyao@xxxxxxxxxx> wrote:
> 
> 
> 
> On 9/3/2024 23:04, Ard Biesheuvel wrote:
> > On Tue, 3 Sept 2024 at 03:39, Tangnianyao <tangnianyao@xxxxxxxxxx> wrote:
> >>
> >>
> >> On 9/3/2024 5:26, Ard Biesheuvel wrote:
> >>> On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz@xxxxxxxxxx> wrote:
> >>>> On Sat, 31 Aug 2024 08:56:23 +0100,
> >>>> Ard Biesheuvel <ardb@xxxxxxxxxx> 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.
> >
> > .
> >
> 
> Process is different between host and guest in arch/arm64, arch_get_random_seed_longs.
> (1) In host , smccc_trng_available is false, it get randomness from RNDRRS.
> 
> (2) In guest, smccc_trng_available is true, because kvm emulate it. Guest use smccc trng
> and hvc, and trap to host kvm. Then in host call stack:
> kvm_smccc_call_handler
> kvm_trng_call
> kvm_trng_do_rnd
> get_random_long
> ...
> arch_get_random_seed_longs
> 
> host get randomness as (1) and return random u64 to guest.
> So the randomness guest finally get is from RNDRRS too.
> Can we let guest get randomness directly from RNDRRS, not using hvc first?
> The process for guest like (1):
> 1) kvm not emulated smccc trng for guest
> 2) guest check smccc trng, and get smccc_trng_available=false
> 3) guest get randomness from RNDRRS

I think I gave you the answer to this in my first reply [1].

	M.

[1] https://lore.kernel.org/all/86zfotuoio.wl-maz@xxxxxxxxxx/

-- 
Without deviation from the norm, progress is not possible.