OvmfPkg: execute option ROM images regardless of Secure Boot

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