On Mon, Mar 18, 2024 at 08:54:08AM -0700, mhkelley58@xxxxxxxxx wrote: > From: Michael Kelley <mhklinux@xxxxxxxxxxx> > > A Hyper-V host provides its guest VMs with entropy in a custom ACPI > table named "OEM0". The entropy bits are updated each time Hyper-V > boots the VM, and are suitable for seeding the Linux guest random > number generator (rng). See a brief description of OEM0 in [1]. > > Generation 2 VMs on Hyper-V use UEFI to boot. Existing EFI code in > Linux seeds the rng with entropy bits from the EFI_RNG_PROTOCOL. > Via this path, the rng is seeded very early during boot with good > entropy. The ACPI OEM0 table provided in such VMs is an additional > source of entropy. > > Generation 1 VMs on Hyper-V boot from BIOS. For these VMs, Linux > doesn't currently get any entropy from the Hyper-V host. While this > is not fundamentally broken because Linux can generate its own entropy, > using the Hyper-V host provided entropy would get the rng off to a > better start and would do so earlier in the boot process. > > Improve the rng seeding for Generation 1 VMs by having Hyper-V specific > code in Linux take advantage of the OEM0 table to seed the rng. For > Generation 2 VMs, use the OEM0 table to provide additional entropy > beyond the EFI_RNG_PROTOCOL. Because the OEM0 table is custom to > Hyper-V, parse it directly in the Hyper-V code in the Linux kernel > and use add_bootloader_randomness() to add it to the rng. Once the > entropy bits are read from OEM0, zero them out in the table so > they don't appear in /sys/firmware/acpi/tables/OEM0 in the running > VM. The zero'ing is done out of an abundance of caution to avoid > potential security risks to the rng. Also set the OEM0 data length > to zero so a kexec or other subsequent use of the table won't try > to use the zero'ed bits. > > [1] https://download.microsoft.com/download/1/c/9/1c9813b8-089c-4fef-b2ad-ad80e79403ba/Whitepaper%20-%20The%20Windows%2010%20random%20number%20generation%20infrastructure.pdf > > Signed-off-by: Michael Kelley <mhklinux@xxxxxxxxxxx> Applied to hyperv-next. Thanks. Long gave his review in the last version. I assumed he's at least onboard with the general idea here. Time is tight, so I applied this patch without waiting for Long's ack again. Long, if you have objections, please speak up.
