diff options
author | Laszlo Ersek <lersek@redhat.com> | 2016-01-07 18:48:17 +0000 |
---|---|---|
committer | lersek <lersek@Edk2> | 2016-01-07 18:48:17 +0000 |
commit | 1fea9ddb4e3fd696f54ab3d9dbf4d905f59113b1 (patch) | |
tree | 7662dfb9cdb406d9a9966d910c199efb89ac0e7c /OvmfPkg/OvmfPkgIa32.dsc | |
parent | 65d2bf42235d04f6e12ac80b661ab4aa0484bd6e (diff) | |
download | edk2-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.dsc | 4 |
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
|