qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

RE: [PATCH 1/3] hw/misc: Introduce AMD/Xilix Versal TRNG device


From: Ho, Tong
Subject: RE: [PATCH 1/3] hw/misc: Introduce AMD/Xilix Versal TRNG device
Date: Fri, 1 Sep 2023 04:16:43 +0000

Hi Richard,

Thanks for your input.

I have questions regarding using qemu/guest-random.h for QEMU device models.

Using qemu/guest-random.h, how can this TRNG model ensure its independence from
other uses of the same qemu_guest_getrandom() and qemu_guest_random_seed_*()?

By "other uses", I mean components and/or devices using qemu/guest-random.h but 
unrelated to this Xilinx Versal TRNG device.

By "independent", I mean the Xilinx Versal TRNG device is:

1. Not impacted by other uses that may or may not need to set the '-seed' 
option, and

2. Not impacting other uses just because a Xilinx Versal machine user decides 
to use deterministic mode *only" for this TRNG device.

Also, I am at a loss in how unrelated QEMU devices can remain independent when:

3. qemu/guest-random.h uses '__thread' variable for GRand context, but

4. QEMU devices run mostly as co-routines and not as separate threads.

I suppose the Versal TRNG implementation could use g_rand_*() directly,
having a GRand object in the device state and seeding through 
g_rand_set_seed_array().

Best regards,
Tong Ho

-----Original Message-----
From: Richard Henderson <richard.henderson@linaro.org> 
Sent: Thursday, August 31, 2023 4:45 PM
To: Ho, Tong <tong.ho@amd.com>; qemu-arm@nongnu.org
Cc: qemu-devel@nongnu.org; alistair@alistair23.me; edgar.iglesias@gmail.com; 
peter.maydell@linaro.org
Subject: Re: [PATCH 1/3] hw/misc: Introduce AMD/Xilix Versal TRNG device

On 8/31/23 10:18, Tong Ho wrote:
> This adds a non-cryptographic grade implementation of the model for 
> the True Random Number Generator (TRNG) component in AMD/Xilinx Versal 
> device family.
> 
> This model is only intended for non-real world testing of guest 
> software, where cryptographically strong TRNG is not needed.
> 
> This model supports versions 1 & 2 of the Versal TRNG, with default to 
> be version 2; the 'hw-version' uint32 property can be set to 0x0100 to 
> override the default.
> 
> Other implemented properties:
> - 'forced-prng', uint64
>    When set to non-zero, "true random reseed" is replaced by
>    deterministic reseed based on the given value and other
>    deterministic parameters, even when guest software has
>    configured the TRNG as "true random reseed".  This option
>    allows guest software to reproduce data-dependent defects.
> 
> - 'fips-fault-events', uint32, bit-mask
>    bit 3: Triggers the SP800-90B entropy health test fault irq
>    bit 1: Triggers the FIPS 140-2 continuous test fault irq
> 
> Signed-off-by: Tong Ho<tong.ho@amd.com>
> ---
>   hw/misc/Kconfig                    |   3 +
>   hw/misc/meson.build                |   3 +
>   hw/misc/xlnx-versal-trng.c         | 725 +++++++++++++++++++++++++++++
>   include/hw/misc/xlnx-versal-trng.h |  58 +++
>   4 files changed, 789 insertions(+)
>   create mode 100644 hw/misc/xlnx-versal-trng.c
>   create mode 100644 include/hw/misc/xlnx-versal-trng.h

I don't think you should be inventing another PRNG, or related properties.

We already have qemu/guest-random.h, and the -seed command-line parameter to 
force the use of a deterministic PRNG with a given seed value.


r~

reply via email to

[Prev in Thread] Current Thread [Next in Thread]