|
|
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 |
|