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.hender...@linaro.org> Sent: Thursday, August 31, 2023 4:45 PM To: Ho, Tong <tong...@amd.com>; qemu-...@nongnu.org Cc: qemu-devel@nongnu.org; alist...@alistair23.me; edgar.igles...@gmail.com; peter.mayd...@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...@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~
