render / rpms / edk2

Forked from rpms/edk2 3 months ago
Clone

Blame SOURCES/0027-Revert-OvmfPkg-use-generic-QEMU-image-loader-for-sec.patch

3e2dc0
From 74e5313dfa6719f7990c7e175e035d17c9b3f657 Mon Sep 17 00:00:00 2001
3e2dc0
From: Laszlo Ersek <lersek@redhat.com>
3e2dc0
Date: Fri, 5 Jun 2020 23:44:43 +0200
3e2dc0
Subject: Revert "OvmfPkg: use generic QEMU image loader for secure boot
3e2dc0
 enabled builds"
3e2dc0
3e2dc0
Notes about the RHEL-8.2/20190904-37eef91017ad [edk2-stable201908] ->
3e2dc0
RHEL-8.3/20200603-ca407c7246bf [edk2-stable202005] rebase:
3e2dc0
3e2dc0
- new patch (to be dropped later, hopefully)
3e2dc0
3e2dc0
This reverts commit ced77332cab626f35fbdb36630be27303d289d79.
3e2dc0
3e2dc0
Upstream commit ced77332cab6 ("OvmfPkg: use generic QEMU image loader for
3e2dc0
secure boot enabled builds", 2020-03-05) changes the "Secure Boot threat
3e2dc0
model" in a way that is incompatible with at least two use cases.
3e2dc0
3e2dc0
Namely, OVMF has always considered kernel images direct-booted via fw_cfg
3e2dc0
as trusted, bypassing Secure Boot validation. While that approach is
3e2dc0
rooted in a technicality (namely, OVMF doesn't load such images with the
3e2dc0
LoadImage() UEFI boot service / through the UEFI stub, but with the
3e2dc0
Linux/x86 Boot Protocol), that doesn't mean it's wrong. The direct-booted
3e2dc0
kernel from fw_cfg comes from the host side, and Secure Boot in the guest
3e2dc0
is a barrier between the guest firmware and the guest operating system --
3e2dc0
it's not a barrier between host and guest.
3e2dc0
3e2dc0
Upstream commit ced77332cab6 points out that the above (historical) OVMF
3e2dc0
behavior differs from ArmVirtQemu's -- the latter direct-boots kernels
3e2dc0
from fw_cfg with the LoadImage() / StartImage() boot services. While that
3e2dc0
difference indeed exists between OVMF and ArmVirtQemu, it's not relevant
3e2dc0
for RHEL downstream. That's because we never build the ArmVirtQemu
3e2dc0
firmware with the Secure Boot feature, so LoadImage() can never reject the
3e2dc0
direct-booted kernel due to a signing issue.
3e2dc0
3e2dc0
Subjecting a kernel direct-booted via fw_cfg to Secure Boot verification
3e2dc0
breaks at least two use cases with OVMF:
3e2dc0
3e2dc0
- It breaks the %check stage in the SPEC file.
3e2dc0
3e2dc0
  In that stage, we use the "ovmf-vars-generator" utility from the
3e2dc0
  "qemu-ovmf-secureboot" project, for verifying whether the Secure Boot
3e2dc0
  operational mode is enabled. The guest kernel is supposed to boot, and
3e2dc0
  to print "Secure boot enabled".
3e2dc0
3e2dc0
  As guest kernel, we pick whatever host kernel is available in the Brew
3e2dc0
  build root. The kernel in question may be a publicly released RHEL
3e2dc0
  kernel, signed with "Red Hat Secure Boot (signing key 1)", or a
3e2dc0
  development build, signed for example with "Red Hat Secure Boot Signing
3e2dc0
  3 (beta)". Either way, none of these keys are accepted by the
3e2dc0
  certificates that were enrolled by "ovmf-vars-generator" /
3e2dc0
  "EnrollDefaultKeys.efi" in the %build stage. Therefore, the %check stage
3e2dc0
  fails.
3e2dc0
3e2dc0
- It breaks "virt-install --location NETWORK-URL" Linux guest
3e2dc0
  installations, if the variable store template used for the new domain
3e2dc0
  has the Secure Boot operational mode enabled. "virt-install --location"
3e2dc0
  fetches the kernel from the remote OS tree, and passes it to the guest
3e2dc0
  firmware via fw_cfg. Therefore the above symptom appears (even for
3e2dc0
  publicly released OSes).
3e2dc0
3e2dc0
  Importantly, if the user downloads the installer ISO of the publicly
3e2dc0
  released Fedora / RHEL OS, and exposes the ISO to the guest for example
3e2dc0
  as a virtio-scsi CD-ROM, then the installation with "virt-install"
3e2dc0
  (without "--location") does succeed. That's because that way, "shim" is
3e2dc0
  booted first, from the UEFI-bootable CD-ROM. "Shim" does pass Secure
3e2dc0
  Boot verification against the Microsoft certificates, and then it is
3e2dc0
  "shim" that accepts the "Red Hat Secure Boot (signing key 1)" signature
3e2dc0
  on the guest kernel.
3e2dc0
3e2dc0
Some ways to approach this problem (without reverting upstream commit
3e2dc0
ced77332cab6):
3e2dc0
3e2dc0
- Equip "ovmf-vars-generator" / "EnrollDefaultKeys.efi" to enroll the
3e2dc0
  public half of "Red Hat Secure Boot (signing key 1)" in the %build
3e2dc0
  stage. Use a publicly released RHEL kernel in the %check stage.
3e2dc0
3e2dc0
  Downsides:
3e2dc0
3e2dc0
  - The Brew build root does not offer any particular released RHEL
3e2dc0
    kernel, so either the %check stage would have to download it, or the
3e2dc0
    SRPM would have to bundle it. However, Brew build environments do not
3e2dc0
    have unfettered network access (rightly so), so the download wouldn't
3e2dc0
    work. Furthermore, for bundling with the SRPM, such a kernel image
3e2dc0
    could be considered too large.
3e2dc0
3e2dc0
  - Does not solve the "virt-install --location" issue for other vendors'
3e2dc0
    signed kernels.
3e2dc0
3e2dc0
- Invoke "ovmf-vars-generator" / "EnrollDefaultKeys.efi" multiple times
3e2dc0
  during %build, to create multiple varstore templates. One that would
3e2dc0
  accept publicly released RHEL kernels, and another to accept development
3e2dc0
  kernels. Don't try to use a particular guest kernel for verification;
3e2dc0
  instead, check what kernel Brew offers in the build environment, and use
3e2dc0
  the varstore template matching *that* kernel.
3e2dc0
3e2dc0
  Downsides:
3e2dc0
3e2dc0
  - It may be considered useless to perform %check with a varstore
3e2dc0
    template that is *not* the one that we ship.
3e2dc0
3e2dc0
  - Does not solve the "virt-install --location" issue for other vendors'
3e2dc0
    signed kernels.
3e2dc0
3e2dc0
- Sign the RHEL kernels such that the currently enrolled certificates
3e2dc0
  accept them.
3e2dc0
3e2dc0
  Downsides:
3e2dc0
3e2dc0
  - Not feasible at all; it would require Microsoft to sign our kernels.
3e2dc0
    "Shim" exists exactly to eliminate such signing requirements.
3e2dc0
3e2dc0
- Modify "virt-install --location NETWORK-URL" such that it download a
3e2dc0
  complete (UEFI-bootable) installer ISO image, rather than broken-out
3e2dc0
  vmlinuz / initrd files. In other words, replace direct (fw_cfg) kernel
3e2dc0
  boot with a CD-ROM / "shim" boot, internally to "virt-install".
3e2dc0
3e2dc0
  Downsides:
3e2dc0
3e2dc0
  - Defeats the goal of "virt-install --location NETWORK-URL", and defeats
3e2dc0
    the network installation method of (for example) Anaconda.
3e2dc0
3e2dc0
For now, revert upstream commit ced77332cab6, in order to return to the
3e2dc0
model we had used in RHEL-8.2 and before. The following ticket has been
3e2dc0
filed to investigate the problem separately:
3e2dc0
<https://bugzilla.redhat.com/show_bug.cgi?id=1844653>.
3e2dc0
3e2dc0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
3e2dc0
---
3e2dc0
 OvmfPkg/OvmfPkgIa32.dsc    | 4 ----
3e2dc0
 OvmfPkg/OvmfPkgIa32X64.dsc | 4 ----
3e2dc0
 OvmfPkg/OvmfPkgX64.dsc     | 4 ----
3e2dc0
 3 files changed, 12 deletions(-)
3e2dc0
3e2dc0
diff --git a/OvmfPkg/OvmfPkgIa32.dsc b/OvmfPkg/OvmfPkgIa32.dsc
3e2dc0
index e8868136d8..5b1e757cb9 100644
3e2dc0
--- a/OvmfPkg/OvmfPkgIa32.dsc
3e2dc0
+++ b/OvmfPkg/OvmfPkgIa32.dsc
3e2dc0
@@ -379,11 +379,7 @@
3e2dc0
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
3e2dc0
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
3e2dc0
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
3e2dc0
-!if $(SECURE_BOOT_ENABLE) == TRUE
3e2dc0
-  QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
3e2dc0
-!else
3e2dc0
   QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
3e2dc0
-!endif
3e2dc0
 !if $(TPM_ENABLE) == TRUE
3e2dc0
   Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.inf
3e2dc0
   Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
3e2dc0
diff --git a/OvmfPkg/OvmfPkgIa32X64.dsc b/OvmfPkg/OvmfPkgIa32X64.dsc
3e2dc0
index d05275a324..5dffc32105 100644
3e2dc0
--- a/OvmfPkg/OvmfPkgIa32X64.dsc
3e2dc0
+++ b/OvmfPkg/OvmfPkgIa32X64.dsc
3e2dc0
@@ -383,11 +383,7 @@
3e2dc0
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
3e2dc0
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
3e2dc0
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
3e2dc0
-!if $(SECURE_BOOT_ENABLE) == TRUE
3e2dc0
-  QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
3e2dc0
-!else
3e2dc0
   QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
3e2dc0
-!endif
3e2dc0
 !if $(TPM_ENABLE) == TRUE
3e2dc0
   Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.inf
3e2dc0
   Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
3e2dc0
diff --git a/OvmfPkg/OvmfPkgX64.dsc b/OvmfPkg/OvmfPkgX64.dsc
3e2dc0
index cac4cecf18..a2a76fdeea 100644
3e2dc0
--- a/OvmfPkg/OvmfPkgX64.dsc
3e2dc0
+++ b/OvmfPkg/OvmfPkgX64.dsc
3e2dc0
@@ -383,11 +383,7 @@
3e2dc0
   PciLib|OvmfPkg/Library/DxePciLibI440FxQ35/DxePciLibI440FxQ35.inf
3e2dc0
   MpInitLib|UefiCpuPkg/Library/MpInitLib/DxeMpInitLib.inf
3e2dc0
   QemuFwCfgS3Lib|OvmfPkg/Library/QemuFwCfgS3Lib/DxeQemuFwCfgS3LibFwCfg.inf
3e2dc0
-!if $(SECURE_BOOT_ENABLE) == TRUE
3e2dc0
-  QemuLoadImageLib|OvmfPkg/Library/GenericQemuLoadImageLib/GenericQemuLoadImageLib.inf
3e2dc0
-!else
3e2dc0
   QemuLoadImageLib|OvmfPkg/Library/X86QemuLoadImageLib/X86QemuLoadImageLib.inf
3e2dc0
-!endif
3e2dc0
 !if $(TPM_ENABLE) == TRUE
3e2dc0
   Tpm12DeviceLib|SecurityPkg/Library/Tpm12DeviceLibTcg/Tpm12DeviceLibTcg.inf
3e2dc0
   Tpm2DeviceLib|SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
3e2dc0
-- 
3e2dc0
2.18.1
3e2dc0