aboutsummaryrefslogtreecommitdiff
path: root/lldb/source/Plugins/ScriptInterpreter/Python/ScriptedThreadPythonInterface.cpp
diff options
context:
space:
mode:
authorWarner Losh <imp@FreeBSD.org>2026-09-24 14:35:45 +0000
committerWarner Losh <imp@FreeBSD.org>2026-09-26 06:43:53 +0000
commit58741fa51dc207123c18b3a4125af99cab798898 (patch)
treead69597289182aad64646ced92e357ae0a9d8278 /lldb/source/Plugins/ScriptInterpreter/Python/ScriptedThreadPythonInterface.cpp
parent102adf88e6e8f83a9ab9769732d168c501f8eb6c (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