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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <CAMj1kXGyJSwD=ok=Ag11mMh3d6onQkN0b_-iVwVDdyrwk5rj6Q@mail.gmail.com>
Date: Tue, 3 Sep 2024 17:04:30 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Tangnianyao <tangnianyao@...wei.com>
Cc: Marc Zyngier <maz@...nel.org>, Will Deacon <will@...nel.org>, oliver.upton@...ux.dev, 
	linux-arm-kernel@...ts.infradead.org, linux-kernel@...r.kernel.org, 
	kvmarm@...ts.linux.dev, "guoyang (C)" <guoyang2@...wei.com>
Subject: Re: Question on get random long worse in VM than on host

On Tue, 3 Sept 2024 at 03:39, Tangnianyao <tangnianyao@...wei.com> wrote:
>
>
>
> On 9/3/2024 5:26, Ard Biesheuvel wrote:
> > On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz@...nel.org> wrote:
> >> On Sat, 31 Aug 2024 08:56:23 +0100,
> >> Ard Biesheuvel <ardb@...nel.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.