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: <f39ccb21-cc28-b878-bf5e-e81e378a299e@huawei.com>
Date: Tue, 3 Sep 2024 09:39:24 +0800
From: Tangnianyao <tangnianyao@...wei.com>
To: Ard Biesheuvel <ardb@...nel.org>, Marc Zyngier <maz@...nel.org>
CC: 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 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?

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.