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