Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 1356913 - fix use-without-initialization in EnrollDefaultKeys.efi
Summary: fix use-without-initialization in EnrollDefaultKeys.efi
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: ovmf
Version: 7.3
Hardware: Unspecified
OS: Unspecified
Target Milestone: rc
: ---
Assignee: Laszlo Ersek
QA Contact: aihua liang
Depends On:
TreeView+ depends on / blocked
Reported: 2016-07-15 09:20 UTC by Laszlo Ersek
Modified: 2016-11-04 08:41 UTC (History)
5 users (show)

Fixed In Version: ovmf-20160608-3.git988715a.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2016-11-04 08:41:35 UTC
Target Upstream Version:

Attachments (Terms of Use)

System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2608 normal SHIPPED_LIVE ovmf bug fix and enhancement update 2016-11-03 15:27:02 UTC

Description Laszlo Ersek 2016-07-15 09:20:06 UTC
*** Description of problem:
The EnrollListOfX509Certs() function reaches the first

  EFI_ERROR (Status) 

check without Status being ever initialized or assigned, if the first (= size computation) loop before it succeeds. This is undefined behavior, as Status has automatic storage duration, and at this point, indeterminate value.

The issue has never been experienced in practice before, but Ard's upstream edk2 work to enable gcc -O2 optimization for X64 has exposed it:

Given that EnrollDefaultKeys.efi is downstream-only (although Open Source, of course), we have to fix this in downstream; no rebase will fix it for us.

I'll also send Gerd an updated (squashed) patch for EnrollDefaultKeys.efi, for his own personal RPMs, and for the Fedora package.

*** Version-Release number of selected component (if applicable):

*** How reproducible:
Not reproducible unless built with Ard's upstream build infrastructure changes.

*** Actual results:
EnrollDefaultKeys.efi reports an error even when it should succeed:

info: SetupMode=1 SecureBoot=0 SecureBootEnable=1 CustomMode=1 VendorKeys=0
error: EnrollListOfX509Certs("db",
D719B2CB-3D3A-4596-A3BC-DAD00E67656F): Invalid Parameter

*** Expected results:
info: SetupMode=1 SecureBoot=0 SecureBootEnable=1 CustomMode=1 VendorKeys=0
info: SetupMode=0 SecureBoot=1 SecureBootEnable=1 CustomMode=0 VendorKeys=0
info: success

*** Additional info:
Sanity testing (key enrollment, Secure Boot verification) suffices for testing. (Already part of QE's OVMF test plan.)

Comment 2 Miroslav Rezanina 2016-08-04 11:48:48 UTC
Fix included in ovmf-20160608-3.git988715a.el7

Comment 4 aihua liang 2016-09-12 11:17:24 UTC
Test it in OVMF Function test, no problem exist with OVMF SB.
Verified Version:
 Kernel version:3.10.0-504.el7.x86_64
 qemu-kvm-rhev version:qemu-kvm-rhev-2.6.0-22.el7.x86_64
 OVMF version:OVMF-20160608-3.git988715a.el7.noarch

Comment 6 errata-xmlrpc 2016-11-04 08:41:35 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.

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