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: <CAMj1kXF3JrDs=xvRmvTxS9du1F-gjSVe5qVZrPO5JLT5ho0riA@mail.gmail.com>
Date: Mon, 2 Sep 2024 23:26:32 +0200
From: Ard Biesheuvel <ardb@...nel.org>
To: Marc Zyngier <maz@...nel.org>
Cc: Tangnianyao <tangnianyao@...wei.com>, 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 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.