Question on get random long worse in VM than on host

Question on get random long worse in VM than on host

[Tangnianyao]

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.


Thanks for your help.

Nianyao

Re: Question on get random long worse in VM than on host

[Marc Zyngier]

[+ Ard, who actually understands the whole RNG thing]

On Sat, 31 Aug 2024 04:34:33 +0100,
Tangnianyao <tangnianyao@huawei.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.

Re: Question on get random long worse in VM than on host

[Ard Biesheuvel]

On Sat, 31 Aug 2024 at 09:42, Marc Zyngier <maz@kernel.org> wrote:
>
> [+ Ard, who actually understands the whole RNG thing]
>
> On Sat, 31 Aug 2024 04:34:33 +0100,
> Tangnianyao <tangnianyao@huawei.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.

Re: Question on get random long worse in VM than on host

[Marc Zyngier]

On Sat, 31 Aug 2024 08:56:23 +0100,
Ard Biesheuvel <ardb@kernel.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?

Thanks,

	M.

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

Re: Question on get random long worse in VM than on host

[Ard Biesheuvel]

On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz@kernel.org> wrote:
>
> On Sat, 31 Aug 2024 08:56:23 +0100,
> Ard Biesheuvel <ardb@kernel.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.

Re: Question on get random long worse in VM than on host

[Tangnianyao]

On 9/3/2024 5:26, Ard Biesheuvel wrote:
> On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz@kernel.org> wrote:
>> On Sat, 31 Aug 2024 08:56:23 +0100,
>> Ard Biesheuvel <ardb@kernel.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.

Re: Question on get random long worse in VM than on host

[Ard Biesheuvel]

On Tue, 3 Sept 2024 at 03:39, Tangnianyao <tangnianyao@huawei.com> wrote:
>
>
>
> On 9/3/2024 5:26, Ard Biesheuvel wrote:
> > On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz@kernel.org> wrote:
> >> On Sat, 31 Aug 2024 08:56:23 +0100,
> >> Ard Biesheuvel <ardb@kernel.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.

Re: Question on get random long worse in VM than on host

[Tangnianyao]

On 9/3/2024 23:04, Ard Biesheuvel wrote:
> On Tue, 3 Sept 2024 at 03:39, Tangnianyao <tangnianyao@huawei.com> wrote:
>>
>>
>> On 9/3/2024 5:26, Ard Biesheuvel wrote:
>>> On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz@kernel.org> wrote:
>>>> On Sat, 31 Aug 2024 08:56:23 +0100,
>>>> Ard Biesheuvel <ardb@kernel.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.

Re: Question on get random long worse in VM than on host

[Marc Zyngier]

On Thu, 05 Sep 2024 04:12:42 +0100,
Tangnianyao <tangnianyao@huawei.com> wrote:
> 
> 
> 
> On 9/3/2024 23:04, Ard Biesheuvel wrote:
> > On Tue, 3 Sept 2024 at 03:39, Tangnianyao <tangnianyao@huawei.com> wrote:
> >>
> >>
> >> On 9/3/2024 5:26, Ard Biesheuvel wrote:
> >>> On Sat, 31 Aug 2024 at 10:14, Marc Zyngier <maz@kernel.org> wrote:
> >>>> On Sat, 31 Aug 2024 08:56:23 +0100,
> >>>> Ard Biesheuvel <ardb@kernel.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

I think I gave you the answer to this in my first reply [1].

	M.

[1] https://lore.kernel.org/all/86zfotuoio.wl-maz@kernel.org/

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

Re: Question on get random long worse in VM than on host

[Tangnianyao]

On 9/5/2024 16:17, Marc Zyngier wrote:
> [...]
>> 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
> I think I gave you the answer to this in my first reply [1].
>
> 	M.
>
> [1] https://lore.kernel.org/all/86zfotuoio.wl-maz@kernel.org/
>

Thank you Marc, I've missed this email.
Userspace should control  whether expose TRNG to guest.

Thanks.
Nianyao