CVS commit: [netbsd-11] src/sys/dev/acpi

Module Name:	src
Committed By:	martin
Date:		Sat Jun 27 10:46:19 UTC 2026

Modified Files:
	src/sys/dev/acpi [netbsd-11]: acpi.c

Log Message:
Pull up following revision(s) (requested by tls in ticket #317):

	sys/dev/acpi/acpi.c: revision 1.305
	sys/dev/acpi/acpi.c: revision 1.306

Hyper-V passes bootstrap entropy to guests via the ACPI OEM0 table.  Use it.

We verify that the OEM0 table has the correct Microsoft IDs, skip the header,
feed the remaining contents to the kernel entropy pool, and wipe them in-place
to prevent later extraction via /dev/acpi (e.g. with acpidump).  This interface
doesn't seem to be documented but we handle it the same way Microsoft's own
Linux driver does.

acpi(4): Leave Hyper-V rndsource attached.

This way, it will be reported through rndctl(8) rather than only by
grepping through dmesg, and rndctl(8) can control it, e.g. if it
turns out something is wrong with that but not with RDSEED on the
same virtual CPU, you can use `rndctl -Ed "Hyper-V OEM0"' to discount
it and the system will gather fresh samples from RDSEED instead.

The same problem could in principle happen with other removable
rndsources like ualea(4), and we don't really have a good way to deal
with that -- either to configure the system up front to discount a
hot-pluggable rndsource that hasn't yet been plugged in, or to
retroactively discount a removable rndsource that was already
removed.  But this one isn't hot-pluggable or removable, so keeping
it around is enough to sidestep this problem.


To generate a diff of this commit:
cvs rdiff -u -r1.303 -r1.303.2.1 src/sys/dev/acpi/acpi.c

Please note that diffs are not public domain; they are subject to the
copyright notices on the relevant files.