summaryrefslogtreecommitdiff
path: root/OvmfPkg/OvmfPkgIa32.dsc
diff options
context:
space:
mode:
authorLaszlo Ersek <lersek@redhat.com>2016-01-07 18:48:17 +0000
committerlersek <lersek@Edk2>2016-01-07 18:48:17 +0000
commit1fea9ddb4e3fd696f54ab3d9dbf4d905f59113b1 (patch)
tree7662dfb9cdb406d9a9966d910c199efb89ac0e7c /OvmfPkg/OvmfPkgIa32.dsc
parent65d2bf42235d04f6e12ac80b661ab4aa0484bd6e (diff)
downloadedk2-platforms-1fea9ddb4e3fd696f54ab3d9dbf4d905f59113b1.tar.xz
OvmfPkg: execute option ROM images regardless of Secure Boot
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 <pbonzini@redhat.com> Cc: Gerd Hoffmann <kraxel@redhat.com> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Jordan Justen <jordan.l.justen@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com> git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19614 6f19259b-4bc3-4df7-8a09-765794883524
Diffstat (limited to 'OvmfPkg/OvmfPkgIa32.dsc')
-rw-r--r--OvmfPkg/OvmfPkgIa32.dsc4
1 files changed, 4 insertions, 0 deletions
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
index 9d53adc908..a6d8d63e8f 100644
--- a/OvmfPkg/OvmfPkgIa32.dsc
+++ b/OvmfPkg/OvmfPkgIa32.dsc
@@ -381,6 +381,10 @@
gUefiCpuPkgTokenSpaceGuid.PcdCpuSmmApSyncTimeout|100000
!endif
+!if $(SECURE_BOOT_ENABLE) == TRUE
+ gEfiSecurityPkgTokenSpaceGuid.PcdOptionRomImageVerificationPolicy|0x00
+!endif
+
# IRQs 5, 9, 10, 11 are level-triggered
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel|0x0E20