Message-ID: <bdf1471e-56aa-893c-0336-81828c8cb5c1@huawei.com>
Date: Thu, 5 Sep 2024 11:12:42 +0800
From: Tangnianyao <tangnianyao@...wei.com>
To: Ard Biesheuvel <ardb@...nel.org>
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 9/3/2024 23:04, Ard Biesheuvel wrote:
> 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.
>
> .
>

Process is different between host and guest in arch/arm64, arch_get_random_seed_longs.
(1) In host , smccc_trng_available is false, it get randomness from RNDRRS.

(2) In guest, smccc_trng_available is true, because kvm emulate it. Guest use smccc trng
and hvc, and trap to host kvm. Then in host call stack:
kvm_smccc_call_handler
kvm_trng_call
kvm_trng_do_rnd
get_random_long
...
arch_get_random_seed_longs

host get randomness as (1) and return random u64 to guest.
So the randomness guest finally get is from RNDRRS too.
Can we let guest get randomness directly from RNDRRS, not using hvc first?
The process for guest like (1):
1) kvm not emulated smccc trng for guest
2) guest check smccc trng, and get smccc_trng_available=false
3) guest get randomness from RNDRRS

Thanks.

Powered by blists - more mailing lists