Bug 1202819 - OVMF: secure boot limitations
Summary: OVMF: secure boot limitations
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ovmf
Version: 7.1
Hardware: x86_64
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: aihua liang
Jiri Herrmann
URL:
Whiteboard:
Depends On: 1202822 1271404
Blocks: 1305606 1313485 1086864
TreeView+ depends on / blocked
 
Reported: 2015-03-17 13:49 UTC by Ademar Reis
Modified: 2016-11-04 08:39 UTC (History)
10 users (show)

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.
Clone Of:
Environment:
Last Closed: 2016-11-04 08:39:17 UTC
Target Upstream Version:


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Bugzilla 1204696 None CLOSED Expose PM system states in fw_cfg file on Q35 2019-06-21 10:13:39 UTC
Red Hat Product Errata RHBA-2016:2608 normal SHIPPED_LIVE ovmf bug fix and enhancement update 2016-11-03 15:27:02 UTC

Internal Links: 1204696

Description Ademar Reis 2015-03-17 13:49:25 UTC
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.

Comment 2 Laszlo Ersek 2015-04-08 08:29:28 UTC
See also bug 1202822 comment 1 for QemuFlashFvbServicesRuntimeDxe implications.

Comment 4 Laszlo Ersek 2015-04-10 09:03:57 UTC
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

Comment 6 Laszlo Ersek 2015-05-05 14:23:13 UTC
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

Comment 7 Laszlo Ersek 2015-05-08 18:15:06 UTC
(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.

Comment 8 Laszlo Ersek 2015-05-08 18:55:03 UTC
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

Comment 9 Laszlo Ersek 2015-05-13 08:33:31 UTC
(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.

Comment 10 Laszlo Ersek 2015-05-13 09:41:34 UTC
(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).

Comment 13 Laszlo Ersek 2015-07-24 23:20:55 UTC
Posted upstream v1 (single VCPU, IA32 only):
http://thread.gmane.org/gmane.comp.bios.edk2.devel/329

Comment 14 Laszlo Ersek 2015-10-09 22:00:40 UTC
Posted upstream v2 (singel VCPU, Ia32 only):
http://thread.gmane.org/gmane.comp.bios.edk2.devel/2820

Comment 15 Laszlo Ersek 2015-10-14 22:29:06 UTC
Posted upstream v3 (moving towards MP and X64, with huge help from Paolo):
http://thread.gmane.org/gmane.comp.bios.edk2.devel/3020

Comment 17 Laszlo Ersek 2015-11-03 21:04:49 UTC
Posted v4 (KVM / X64 / MP / S3):
http://thread.gmane.org/gmane.comp.bios.edk2.devel/3788

Comment 18 Laszlo Ersek 2015-11-27 02:37:43 UTC
Posted v5 (with hopefully final tweaks):
http://thread.gmane.org/gmane.comp.bios.edk2.devel/4958

Comment 19 Laszlo Ersek 2015-11-30 18:58:20 UTC
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.

Comment 20 Laszlo Ersek 2015-12-01 12:52:43 UTC
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.

Comment 21 Laszlo Ersek 2015-12-02 17:02:24 UTC
(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.)

Comment 22 Paolo Bonzini 2015-12-02 17:17:37 UTC
> 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.

Comment 23 Laszlo Ersek 2015-12-02 17:49:08 UTC
(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.

Comment 29 Laszlo Ersek 2016-03-17 15:29:57 UTC
The doc text here covers changes from bug 1308678 too.

Comment 30 Laszlo Ersek 2016-04-01 21:30:32 UTC
For QE: verification steps for this bug can be found in bug 1308678 comment 1, step (07) and onward.

Comment 31 aihua liang 2016-09-09 06:53:11 UTC
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

Comment 33 errata-xmlrpc 2016-11-04 08:39:17 UTC
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


Note You need to log in before you can comment on or make changes to this bug.