diff options
| author | Warner Losh <imp@FreeBSD.org> | 2026-09-24 14:35:45 +0000 |
|---|---|---|
| committer | Warner Losh <imp@FreeBSD.org> | 2026-09-26 06:43:53 +0000 |
| commit | 58741fa51dc207123c18b3a4125af99cab798898 (patch) | |
| tree | ad69597289182aad64646ced92e357ae0a9d8278 /lldb/source/Plugins/ScriptInterpreter/Python/ScriptedThreadPythonInterface.cpp | |
| parent | 102adf88e6e8f83a9ab9769732d168c501f8eb6c (diff) | |
boot-test.sh: Add virtio-rng-pci to the EFI RAM-disk netboot qemu invocation
Since the PixieFail security fixes (CVE-2023-45237), EDK II's DxeNetLib --
underneath essentially all of NetworkPkg (Mnp/Arp/Ip4/Dhcp4/Tcp/Http) --
carries a DEPEX on EFI_RNG_PROTOCOL. With no RNG protocol producer
available, that DEPEX is never satisfied and the entire NetworkPkg driver
stack silently fails to load: no error, no assert, it just isn't there.
netboot-efi and netboot-ramdisk never noticed because they only ever touch
the raw EFI_SIMPLE_NETWORK_PROTOCOL via our own net.c, which has no such
dependency. A test that needs EDK II's own NetworkPkg (e.g. one exercising
EFI_HTTP_PROTOCOL) is the first to be affected.
RngDxe can satisfy the DEPEX from the RDRAND instruction alone on a
sufficiently recent edk2 build, but not every installed OVMF is that
recent. -device virtio-rng-pci provides an RNG unconditionally via
VirtioRngDxe, regardless of edk2 vintage or host CPU features.
Unfortunately, the edk2 shipped with qemu lacks the network this needs.
Sponsored by: Netflix
Diffstat (limited to 'lldb/source/Plugins/ScriptInterpreter/Python/ScriptedThreadPythonInterface.cpp')
0 files changed, 0 insertions, 0 deletions
