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: <CAMj1kXGocnZPe4EfzsB6xd2QZacp-a45R5f5f6FDpVtVEXCcGQ@mail.gmail.com>
Date: Sat, 31 Aug 2024 09:56:23 +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 09:42, Marc Zyngier <maz@...nel.org> wrote:
>
> [+ Ard, who actually understands the whole RNG thing]
>
> On Sat, 31 Aug 2024 04:34:33 +0100,
> Tangnianyao <tangnianyao@...wei.com> wrote:
> >
> > Hi, all
> >
> > On ARM64 server(Kunpeng), performance of some syscall cases (like fork
> > and open) in guest, which need random u64, are 10~20% worse than
> > those on host. Because CONFIG_ARCH_HAS_ELF_RANDOMIZE=y and
> > CONFIG_STACKPROTECTOR=y, guest kernel need random u64 and
> > require them from host kvm using hvc.
> >
> > If FEAT_RNG is supported and EL3 firmware not support smccc trng, host
> > kvm finally return random u64 using RNDRRS to guest.
> >
> > Shall we firstly let guest get random u64 from RNDRRS to avoid hvc trap?
> > For example, if host find smccc trng not available, then tell guest smccc
> > trng not available when guest check trng version.
>
> My recollection is that it was a deliberate decision to decouple what
> the host firmware offers from what the guest sees (we can always
> implement the SMCCC TRNG using any mechanism that the host has to
> deliver entropy).
>
> Now, userspace has almost complete freedom to expose what the guest
> sees in terms of PV services. In this particular case, it can write to
> the KVM_REG_ARM_STD_BMAP pseudo register to remove the
> KVM_REG_ARM_STD_BIT_TRNG_V1_0 bit from the bitmap, which will hide the
> functionality.
>
> Isn't this sufficient here? Given that you seem to be micro-optimising
> for a particular platform, this seems like the easiest way to reach
> your goal without having to change anything.
>

On top of that, the guest kernel should not be calling this interface
every single time it needs some randomness. The kernel's entropy pool
should be used, which is reseeded as needed using whichever source of
entropy the system provides, which includes arch_get_random_longs().

If every fork() and open() results in a HVC, we need to fix that regardless.

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.

TL;DR if the layering inside the kernel is correct, none of this
should matter to fork() or open() performance.