Change the image verification policy for option ROM images to 0x00 (ALWAYS_EXECUTE).
While this may not be a good idea for physical platforms (see e.g. <https://trmm.net/Thunderstrike>), on the QEMU platform the benefits seem to outweigh the drawbacks: - For QEMU's virtual PCI devices, and for some assigned PCI devices, the option ROMs come from host-side files, which can never be rewritten from within the guest. Since the host admin has full control over a guest anyway, executing option ROMs that originate from host-side files presents no additional threat to the guest. - For assigned physical PCI devices with option ROMs, the argument is not so clear-cut. In theory a setup could exist where: - the host-side UEFI firmware (with DENY_EXECUTE_ON_SECURITY_VIOLATION) rejects the option ROM of a malicious physical PCI device, but - when the device is assigned to the guest, OVMF executes the option ROM in the guest, - the option ROM breaks out of the guest (using an assumed QEMU vulnerability) and gains QEMU user privileges on the host. However, in order to escalate as far as it would happen on the bare metal with ALWAYS_EXECUTE (i.e., in order to gain firmware-level access on the host), the malicious option ROM would have to break through (1) QEMU, (2) traditional UID and GID based privilege separation on the host, (3) sVirt (SELinux) on the host, (4) the host OS - host firmware boundary. This is not impossible, but not likely enough to discourage the use cases below. - This patch makes it possible to use unsigned iPXE network drivers that QEMU presents in the option ROMs of virtual NICs and assigned SR-IOV VFs, even if Secure Boot is in User Mode or Deployed Mode. - The change also makes it possible to execute unsigned, outdated (revoked), or downright malicious option ROMs of assigned physical devices in guests, for corporate, entertainment, academia, or security research purposes. Cc: Paolo Bonzini <pbonz...@redhat.com> Cc: Gerd Hoffmann <kra...@redhat.com> Cc: Jordan Justen <jordan.l.jus...@intel.com> Cc: Chao Zhang <chao.b.zh...@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <ler...@redhat.com> --- OvmfPkg/OvmfPkgIa32.dsc | 4 ++++ OvmfPkg/OvmfPkgIa32X64.dsc | 4 ++++ OvmfPkg/OvmfPkgX64.dsc | 4 ++++ 3 files changed, 12 insertions(+) diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc index afde345..62065f7 100644 --- a/OvmfPkg/OvmfPkgIa32.dsc +++ b/OvmfPkg/OvmfPkgIa32.dsc @@ -404,6 +404,10 @@ [PcdsFixedAtBuild] gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000 !endif +!if $(SECURE_BOOT_ENABLE) == TRUE + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 +!endif + # IRQs 5, 9, 10, 11 are level-triggered gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc index 2cbd417..d0ff2bb 100644 --- a/OvmfPkg/OvmfPkgIa32X64.dsc +++ b/OvmfPkg/OvmfPkgIa32X64.dsc @@ -410,6 +410,10 @@ [PcdsFixedAtBuild.X64] gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000 !endif +!if $(SECURE_BOOT_ENABLE) == TRUE + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 +!endif + # IRQs 5, 9, 10, 11 are level-triggered gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc index 309b5e2..b848976 100644 --- a/OvmfPkg/OvmfPkgX64.dsc +++ b/OvmfPkg/OvmfPkgX64.dsc @@ -409,6 +409,10 @@ [PcdsFixedAtBuild] gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000 !endif +!if $(SECURE_BOOT_ENABLE) == TRUE + gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00 +!endif + # IRQs 5, 9, 10, 11 are level-triggered gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20 -- 1.8.3.1 _______________________________________________ edk2-devel mailing list edk2-devel@lists.01.org https://lists.01.org/mailman/listinfo/edk2-devel
