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: <86zfotuoio.wl-maz@kernel.org>
Date: Sat, 31 Aug 2024 08:42:23 +0100
From: Marc Zyngier <maz@...nel.org>
To: Tangnianyao <tangnianyao@...wei.com>
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>,
	Ard Biesheuvel <ardb@...nel.org>
Subject: Re: Question on get random long worse in VM than on host

[+ 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.

Thanks,

	M.

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