Created attachment 1547041 [details]
qemu patch

Found the patch.

Oh, and I just noticed your cmdline is using a rhel7 iso, that is not supported. It *may* work but there is no guarantee.

rhel8-branch PR for this - https://github.com/weldr/lorax/pull/658

Hi,

(In reply to Brian Lane from comment #5)
> rhel8-branch PR for this - https://github.com/weldr/lorax/pull/658

I've now checked
<https://github.com/weldr/lorax/pull/658/commits/c4342f8f83c9f41b48b57624d42378db82de1fb2>.
It looks good to me, I'd just like to highlight a fact that may not be
obvious.

"OVMF_CODE.secboot.fd" is the firmware executable. We do not provide
"OVMF_CODE.fd" for the reasons I described to Renaud in email.
Therefore, unconditionally using "OVMF_CODE.secboot.fd", with the
related QEMU flags, is correct in the patch.

"OVMF_VARS.secboot.fd" is a variable store template file. The method the
actual variable store file (a temporary file) is created from the
template is correct (in the pre-patch code already). This is where I'd
like to mention "OVMF_VARS.fd" -- because we still ship "OVMF_VARS.fd".
Let me explan why:

- "OVMF_VARS.secboot.fd" is a variable store template that has the
  Microsoft certificates pre-enrolled, and the Secure Boot operational
  mode pre-enabled. Therefore, if you create the varstore file from this
  template, then the virtual UEFI firmware will only boot such OS boot
  loaders that are appropriately signed. For example, it will boot all
  released Windows OSes from the Windows 8 family upward, it will boot
  all Fedora GA and RHEL GA releases, and so on. It will reject Beta
  builds of RHEL however -- for example.

- "OVMF_VARS.fd" is a variable store template that is logically empty.
  It has no certificates enrolled and the SB operational mode is not
  enabled. Therefore, if you create the varstore file from this
  template, the virtual firmware will accept & launch all UEFI OS boot
  loaders, without SB verification.

Both use cases are valid (that's why we provide both varstore templates,
to accompany the sole "OVMF_CODE.secboot.fd" firmware executable); it
depends on the user / utility which varstore template is the right
choice, for creating the varstore file.

See bug 1561128 for more details.

--*--

By the way: we are implementing automatic UEFI firmware selection in
qemu, edk2, and libvirt. This feature is supposed to eliminate the
"traditional" need for applications launching QEMU with UEFI firmware to
open-code the firmware binary and varstore template pathnames.

- https://bugzilla.redhat.com/show_bug.cgi?id=1546084
- https://bugzilla.redhat.com/show_bug.cgi?id=1600230
- https://bugzilla.redhat.com/show_bug.cgi?id=1564270

Thanks for the clarification. I think it's best to use the one with the pre-enrolled keys unless someone can thing of a good reason not to -- not to mention it works, so why not use it :)

I'm looking forward to automatic firmware selection, that'll make things simpler and more reliable.

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://access.redhat.com/errata/RHBA-2019:3328