Bug 1202819
| Summary: | OVMF: secure boot limitations | ||
|---|---|---|---|
| Product: | Red Hat Enterprise Linux 7 | Reporter: | Ademar Reis <areis> |
| Component: | ovmf | Assignee: | Laszlo Ersek <lersek> |
| Status: | CLOSED ERRATA | QA Contact: | aihua liang <aliang> |
| Severity: | unspecified | Docs Contact: | Jiri Herrmann <jherrman> |
| Priority: | unspecified | ||
| Version: | 7.1 | CC: | chayang, huding, juzhang, knoel, kraxel, lmiksik, mrezanin, pbonzini, pjones, xfu |
| Target Milestone: | rc | Keywords: | Rebase |
| Target Release: | --- | ||
| Hardware: | x86_64 | ||
| OS: | Unspecified | ||
| Whiteboard: | |||
| Fixed In Version: | ovmf-20160202-1.gitd7c0dfa.el7 | Doc Type: | Rebase: Enhancements Only |
| Doc Text: |
* Rebase package(s) to version:
upstream git d7c0dfa
* Highlights and notable enhancements:
The "OVMF-20160202-2.gitd7c0dfa.el7.noarch" binary package
provides two firmware binaries, "OVMF_CODE.fd" and
"OVMF_CODE.secboot.fd".
The firmware binary "OVMF_CODE.fd" lacks the Secure Boot
feature. It can be used with pc-i440fx-rhel7.0.0 and later
i440fx qemu-kvm machine types, and also with the
pc-q35-rhel7.3.0 machine type.
Guests that were installed using "OVMF_CODE.fd" from
earlier versions of the binary RPM may have enabled the
Secure Boot operating mode, for development and testing
purposes only (it was not actually secure). For those
guests, the Secure Boot operating mode will be
transparently disabled at their first shutdown after
upgrading the OVMF package.
The firmware binary "OVMF_CODE.secboot.fd" includes the
Secure Boot feature. It is based on SMM emulation, which is
meant to make it actually secure. This binary can be used
with pc-q35-rhel7.3.0 and later Q35 machine types only, and
it also requires the host kernel to be RHEL-7.3 GA or
later.
OVMF remains Technical Preview in RHEL-7.3.
|
Story Points: | --- |
| Clone Of: | Environment: | ||
| Last Closed: | 2016-11-04 08:39:17 UTC | Type: | Bug |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
| Bug Depends On: | 1202822, 1271404 | ||
| Bug Blocks: | 1086864, 1305606, 1313485 | ||
See also bug 1202822 comment 1 for QemuFlashFvbServicesRuntimeDxe implications. On the PIWG (Platform Init Working Group) mailing list, the following two documents have been recently referenced: "EDK II SMM call topology.pdf" "A_Tour_beyond_BIOS_Implementing_APEI_with_UEFI_White_Paper.pdf" http://sourceforge.net/projects/edk2/files/General%20Documentation/EDK%20II%20SMM%20call%20topology.pdf/download https://firmware.intel.com/sites/default/files/resources/A_Tour_beyond_BIOS_Implementing_APEI_with_UEFI_White_Paper.pdf Prerequisite patch (general Q35 support actually, perhaps worth a separate BZ): "OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges" http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14319 (In reply to Laszlo Ersek from comment #6) > Prerequisite patch (general Q35 support actually, perhaps worth a separate > BZ): > "OvmfPkg: QemuBootOrderLib: parse OFW device path nodes of PCI bridges" > http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14319 Now in SVN as rev 17385. More prep patches: 1 OvmfPkg: split Include/OvmfPlatforms.h 2 OvmfPkg: consolidate POWER_MGMT_REGISTER_Q35() on "Q35MchIch9.h" macros 3 OvmfPkg: consolidate POWER_MGMT_REGISTER_PIIX4() on "I440FxPiix4.h" macros 4 OvmfPkg: extract some bits and port offsets common to Q35 and I440FX 5 OvmfPkg: AcpiS3SaveDxe: fix protocol usage hint in the INF file 6 MdePkg: BaseExtractGuidedSectionLib: allow forced reinit of handler table 7 MdeModulePkg: SmmIplEntry(): don't suppress SMM core startup failure 8 UefiCpuPkg: CpuDxe: optionally save MTRR settings to AcpiNVS memory block 9 UefiCpuPkg: CpuDxe: broadcast MTRR changes to APs 10 UefiCpuPkg: CpuDxe: sync MTRR settings to APs at MP startup 11 UefiCpuPkg: CpuDxe: provide EFI_MP_SERVICES_PROTOCOL when there's no AP http://thread.gmane.org/gmane.comp.bios.tianocore.devel/14495 (In reply to Laszlo Ersek from comment #8) > More prep patches: > 7 MdeModulePkg: SmmIplEntry(): don't suppress SMM core startup failure Now in upstream: SVN r17417 (git commit b07ea4c1). Unfortunately the commit message was not kept intact, but the patch will serve its purpose anyway. (In reply to Laszlo Ersek from comment #8) > More prep patches: > > 1 OvmfPkg: split Include/OvmfPlatforms.h > 2 OvmfPkg: consolidate POWER_MGMT_REGISTER_Q35() on "Q35MchIch9.h" macros > 3 OvmfPkg: consolidate POWER_MGMT_REGISTER_PIIX4() on "I440FxPiix4.h" macros > 4 OvmfPkg: extract some bits and port offsets common to Q35 and I440FX > 5 OvmfPkg: AcpiS3SaveDxe: fix protocol usage hint in the INF file These patches are now upstream (after splitting the first one in two stages); SVN range 17432 through 17437, inclusive (ie. 6 patches). Posted upstream v1 (single VCPU, IA32 only): http://thread.gmane.org/gmane.comp.bios.edk2.devel/329 Posted upstream v2 (singel VCPU, Ia32 only): http://thread.gmane.org/gmane.comp.bios.edk2.devel/2820 Posted upstream v3 (moving towards MP and X64, with huge help from Paolo): http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020 Posted v4 (KVM / X64 / MP / S3): http://thread.gmane.org/gmane.comp.bios.edk2.devel/3788 Posted v5 (with hopefully final tweaks): http://thread.gmane.org/gmane.comp.bios.edk2.devel/4958 Committed v5 to SVN (r19034..r19066). It is not sufficient to backport these patches -- a large set of related patches had been committed earlier, as development progressed, so we shall get this feature with another rebase. This BZ has consequences for packaging -- we'll have to ship a separate "OVMF_CODE.smm.fd" binary for the -D SMM_REQUIRE build. First, the binaries work very differently and the selection between SMM and non-SMM can only be done at build time. Second, the SMM stuff requires Q35 (and we'd like to allow users to play with OVMF even on i440fx). So we'll have to include both binaries separately, and users can choose the specific firmware binary when they create the VM. (In reply to Laszlo Ersek from comment #20) > This BZ has consequences for packaging -- we'll have to ship a separate > "OVMF_CODE.smm.fd" binary for the -D SMM_REQUIRE build. First, the binaries > work very differently and the selection between SMM and non-SMM can only be > done at build time. Second, the SMM stuff requires Q35 (and we'd like to > allow users to play with OVMF even on i440fx). So we'll have to include both > binaries separately, and users can choose the specific firmware binary when > they create the VM. Only the SMM build would be advertized as suitable for "security sensitive" production environments -- this will have to be noted in the Doc Text field on this BZ. (I don't yet know which Doc Type would be most suitable.) > This BZ has consequences for packaging -- we'll have to ship a separate > "OVMF_CODE.smm.fd" binary for the -D SMM_REQUIRE build. Agreed. On the other hand, once OVMF gets out of tech preview I believe we should not distribute the !SMM_REQUIRE firmware anymore, and stop supporting i440FX. > Only the SMM build would be advertized as suitable for "security sensitive" > production environments -- this will have to be noted in the Doc Text field on > this BZ. (I don't yet know which Doc Type would be most suitable.) I think even then we should make it clear that OVMF is tech preview. One requirement for getting out of tech preview is a better interface for key enrollment (UEFI 2.5?)---and possibly a way to control secure boot mode via fw_cfg. (In reply to Paolo Bonzini from comment #22) > > This BZ has consequences for packaging -- we'll have to ship a separate > > "OVMF_CODE.smm.fd" binary for the -D SMM_REQUIRE build. > > Agreed. On the other hand, once OVMF gets out of tech preview I believe we > should not distribute the !SMM_REQUIRE firmware anymore, and stop supporting > i440FX. Ah. I thought we'd get OVMF out of TP for 7.3, due to this BZ being fixed. But, given how new SMM support is, that might be considered reckless. So another minor release where OVMF is TP could be justified, yes. > > Only the SMM build would be advertized as suitable for "security sensitive" > > production environments -- this will have to be noted in the Doc Text field > > on this BZ. (I don't yet know which Doc Type would be most suitable.) > > I think even then we should make it clear that OVMF is tech preview. Okay. > One > requirement for getting out of tech preview is a better interface for key > enrollment (UEFI 2.5?) I don't know if a better interface for key enrollment is necessary for OVMF to get out of TP (this idea has not been raised before), but I think that if we accept this dependency, then UEFI 2.5 should help. Just today I read the sections on AuditMode and DeployedMode, in UEFI 2.5. Despite the new (very nice) state diagram in Figure 77 ("Secure Boot Modes"), the high number of states and transitions is confusing, mostly because the spec contains no use cases and no recommendations for matching OS-level actions. So I went to the UEFI spec bug tracker and checked the associated Mantis item: https://mantis.uefi.org/mantis/view.php?id=1263 (You have to be a member to read it... It's annoying, sorry.) This Mantis ticket contains the Engineering Change Request behind the feature -- which I cannot share here, obviously :( --, and that ECR *does* contain use cases and matching recommendations. What I take away from this is that RHEL (the OS) will likely grow userspace utilities that enable non-interactive key enrollment, based on AuditMode and DeployedMode, *regardless of* virtualization. And then, same as an administrator of a group of physical hosts in a data center enrolled new key material non-interactively, using RHEL (= the bare metal OS), a virt admin would enroll keys in a group of virtual machines, using RHEL (= the guest OS). >---and possibly a way to control secure boot mode via > fw_cfg. In OVMF we already rely on QEMU's "-fw_cfg" switch, to control two simple boolean settings (see commit ab081a50): - opt/ovmf/PcdPropertiesTableEnable - opt/ovmf/PcdSetNxForStack QEMU is not aware of these fw_cfg file names; they need to be agreed upon only by OVMF and the user (= libvirtd). The edk2-specific, boot time-only "SecureBootEnable" variable is also a boolean, so the same -fw_cfg mechanism might prove usable for controlling SecureBoot. The doc text here covers changes from bug 1308678 too. For QE: verification steps for this bug can be found in bug 1308678 comment 1, step (07) and onward. Verified it as the step(07) and onward in bug 1308678 comment, it passed, change its status to "Verified" Verified Version: Kernel Version:3.10.0-500.el7.x86_64 qemu-kvm-version:qemu-kvm-rhev-2.6.0-22.el7.x86_64 OVMF Version:OVMF-20160608-3.git988715a.el7.noarch Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://rhn.redhat.com/errata/RHBA-2016-2608.html |
Discussed OVMF secure boot with Laszlo and he pointed me to the following places where what needs to be developed is documented: - the OVMF whitepaper, sections - Known Secure Boot limitations - Variable store and LockBox in SMRAM - the following Intel whitepapers: - A Tour Beyond BIOS: Implementing UEFI Authenticated Variables in SMM with EDKII - A Tour Beyond BIOS: Implementing S3 resume with EDKII There will be other BZs for missing pieces in QEMU and the kernel as well. See the OVMF Secure boot tracker: bug 1086864.