Kashyap, Daniel, can you please express your preferences about option #1 or #2 in comment 0? Thanks!

I don't think that the mgmt tools should be responsible for creating a BIOS with keys enrolled, because this is something every application will end up needing to reinvent. From an app POV, we need to be able to say in the guest XML "secureboot=on", and have it just work.

IOW, we need to ship something with the keys pre-enrolled, but I don't think it is credible to have this rely on a developer running EnrollDefaultKeys.efi on their laptop, no matter how good they are at making a pristine image. It needs to be automated in brew as for any other software we build for RHEL.

Essentially we need Option 3, which takes best bits of Options 1 & 2. I would suggest that we have part of the OVMF RPM build process which runs EnrollDefaultKeys.efi non-interactively inside brew. It is possible to run QEMU inside brew, since libguestfs does that, though it will use TCG not KVM. AFAIK this shouldn't matter for what we're doing.  So I'd suggest we just take that ovmf-vars-generator script and tailor it so that it can run inside a brew build. It should use the kernel+initrd that are provided by the kernel RPM, not download from a remote URL.

Right, option #3 is entirely doable, and I'm sorry for forgetting about it.
I vaguely remember that I discussed it with someone off-list earlier. I
think at that time I wasn't sure whether depending on qemu at build time was
acceptable.

... Hmmm yes, I found the email:

> Subject: Re: Fwd: ovmf and crypto
> To: Paolo Bonzini <pbonzini>, Daniel P. Berrange
> <berrange>, Nikos Mavrogiannopoulos <nmav>
> Cc: Mark Thacker <mthacker>, Miroslav Rezanina
> <mrezanin>, Tomas Hoger <thoger>
> From: Laszlo Ersek <lersek>
> Message-ID: <d2c85e36-6d2e-b6e9-d4ac-6a595fef644d>
> Date: Fri, 19 Jan 2018 16:50:47 +0100
>
> On 01/19/18 10:15, Paolo Bonzini wrote:
> > [...]
>
> Tangent: Ademar recently informed me of an upcoming (not yet filed) 7.6
> RHBZ that requires OVMF VMs to have Secure Boot enabled (with the
> Microsoft certificates pre-enrolled) at creation.
>
> (Without knowing more, I consider this a packaging question -- my plan is
> to simply provide the varstore template "/usr/share/OVMF/OVMF_VARS.fd"
> such that it has been subjected to "EnrollDefaultKeys.efi". Possibly on my
> machine at packaging time, or else in Brew at build time (but that would
> BuildRequire qemu-kvm-rhev).)
>
> [...]

Thanks for the reminder :)

I had a todo item for myself to package the script up in Fedora, and as part of the build, make it do the enrolling and ship a pre-enrolled image in that same package, so basically option 3, just in a separate base package from edk2-ovmf itself.

I was hoping to get to that later this week, so we should have this in Fedora pretty soon.

Patrick, many thanks for that; can you please describe how the package (build-)dependencies would look like?

(In reply to Patrick Uiterwijk from comment #4)
> I had a todo item for myself to package the script up in Fedora, and as part
> of the build, make it do the enrolling and ship a pre-enrolled image in that
> same package, so basically option 3, just in a separate base package from
> edk2-ovmf itself.

Hi, 

Although we discussed don IRC about the above approach ... re-thinking a bit more, maybe it's nicer / convenient to have the pre-enrolled VARS file / image shipped as part of the EDK2 package itself?

> I was hoping to get to that later this week, so we should have this in
> Fedora pretty soon.

Patrick: Happy to review the Fedora spec if you post one :-)

(In reply to Kashyap Chamarthy from comment #6)
> (In reply to Patrick Uiterwijk from comment #4)
> > I had a todo item for myself to package the script up in Fedora, and as part
> > of the build, make it do the enrolling and ship a pre-enrolled image in that
> > same package, so basically option 3, just in a separate base package from
> > edk2-ovmf itself.
> 
> Hi, 
> 
> Although we discussed don IRC about the above approach ... re-thinking a bit
> more, maybe it's nicer / convenient to have the pre-enrolled VARS file /
> image shipped as part of the EDK2 package itself?

IMHO it is mandatory for pre-enrolled vars to be in the same RPM as the base firmware image. Shipping it separately just introduces possibility of deployment mistakes where user wants SB but forget they needed an extra RPM installed. It'll lead to unhappiness and extra bug reports

(In reply to Daniel Berrange from comment #7)
> IMHO it is mandatory for pre-enrolled vars to be in the same RPM as the base
> firmware image. Shipping it separately just introduces possibility of
> deployment mistakes where user wants SB but forget they needed an extra RPM
> installed. It'll lead to unhappiness and extra bug reports

Makes sense. I'll try to send patches to the edk2 rpms this week.

https://src.fedoraproject.org/rpms/edk2/pull-request/1 is the PR I just submitted for Fedora's edk2.

Related: https://github.com/puiterwijk/qemu-ovmf-secureboot/pull/19

Related: https://github.com/puiterwijk/qemu-ovmf-secureboot/pull/20

Virt QE: for testing this, please create a new VM using the new variable store template file "/usr/share/OVMF/OVMF_VARS.secboot.fd".

Then, attempt to boot (a) any released x86_64 Fedora Live ISO, (b) any released x86_64 RHEL7 installer ISO, (c) any released x86_64 Windows 8 or 10 installer ISO. These should all boot fine, and they should report secure boot as enabled. (To verify that, grep the dmesg in the Linux guests, and run the "Confirm-SecureBootUEFI" command in PowerShell as Admin in Windows <https://docs.microsoft.com/en-us/powershell/module/secureboot/confirm-securebootuefi>.)

Finally, attempt to boot an *unreleased* -- rel-eng or nightly -- x86_64 RHEL7 installer ISO; it shouldn't boot. In addition, also try to boot "/usr/share/OVMF/UefiShell.iso" -- that shouldn't boot either. Thanks.

Further testing options for Virt-QE:

- Since RHEL-7.4 (see RHBZ#1078990), the "dbxtool" utility has been
  available in RHEL7.

  In a VM created against the new varstore template file
  "/usr/share/OVMF/OVMF_VARS.secboot.fd", "dbxtool" testing should work
  fine. Please consult the comments in RHBZ#1078990 for working with
  "dbxtool", especially RHBZ#1078990 comment 33.

- You might want to repeat the Secure Boot Logo Tests (RHBZ#1443351,
  RHBZ#1443361) in a Windows 2016 "HCK client" VM that is created against
  the new varstore template file "/usr/share/OVMF/OVMF_VARS.secboot.fd'.

  NOTE: there is at least one (wrong) test case in the SB Logo Test (the
  automated, non-Manual one) that is expected to fail. It's called
  "VerifyBootServicesVariableBehavior" (see RHBZ#1443351 comment 29). The
  HCK studio periodically refreshes its exception list / filters (or
  whatever they are called) from the net, and then this test case is
  suppressed. However, until those filters are automatically refreshed, the
  test suite might appear as failed.

(The following link, from comment 4 of RHBZ#1078990, might be worth quoting separately, wrt. "dbxtool": <https://fedoraproject.org/w/index.php?title=Changes/UEFISecureBootBlacklistUpdates>.)

Virt-QE: please skip the dbxtool testing for now; see bug 1489942 / bug 1508808 / bug 1516599. I've hit the same "permission denied" / "operation not permitted" error; it's due to an issue in dbxtool, not the firmware (see bug 1516599 comment 12).

Another update on dbxtool testing:

- Fedora 27 and Fedora 28 have two issues (regressions) with dbxtool:
  - I've found the root cause of bug 1516599, which affects the "efivar"
    library underlying dbxtool,
  - I've written, tested & attached the fix to bug 1508808, which affects
    dbxtool itself.
  Once both of those are fixed & built officially in Fedora 27/28, dbxtool
  testing can be used in Fedora 27/28 guests.

- On the other hand, RHEL-7 guests are not affected. Starting with RHEL-7.4,
  we ship dbxtool-7-1.el7 and efivar-31-4.el7, and those are affected by
  none of the above, more recent, regressions. Hence "dbxtool" should work
  fine for testing in RHEL-7.4+ guests.

Fix included in ovmf-20180508-2.gitee3198e672e2.el7

Verified bug with OVMF-20180508-2.gitee3198e672e2.el7.noarch & qemu-kvm-rhev-2.12.0-3.el7.x86_64 & 3.10.0-901.el7.x86_64

According to comment20 & coment26.
Kvm QE tested 2 linux guests(RHEL7.5 and Fedora28) and a win10 guest.

a) Installation RHEL7.5 and Fedora 28 with variable store template file "/usr/share/OVMF/OVMF_VARS.secboot.fd".

result:works well

b)For RHEL7.5 guest

# dmesg|grep -i secure
[    0.000000] Secure boot enabled
[    1.159833] EFI: Loaded cert 'Red Hat Secure Boot (CA key 1): 4016841644ce3a810408050766e8f8a29c65f85c' linked to '.system_keyring'

# service dbxtool status
Redirecting to /bin/systemctl status dbxtool.service
● dbxtool.service - Secure Boot DBX (blacklist) updater
   Loaded: loaded (/usr/lib/systemd/system/dbxtool.service; disabled; vendor preset: disabled)
   Active: active (exited) since Mon 2018-06-11 15:49:48 CST; 7s ago
  Process: 3363 ExecStart=/usr/bin/dbxtool -a /usr/share/dbxtool/ (code=exited, status=0/SUCCESS)
 Main PID: 3363 (code=exited, status=0/SUCCESS

# dbxtool -l
1: {d5c1df0b-1bac-4edf-ba48-08834009ca5a} {sha256} e3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855
2: {microsoft} {sha256} 80b4d96931bf0d02fd91a61e19d14f1da452e66db2408ca8604d411f92659f0a
.....

c)For win10 guest.

run the "Confirm-SecureBootUEFI" command in PowerShell as Admin in Windows guest.

return: True


So, this bug is fixed.  set this as verified.

Thanks!

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/RHSA-2018:3090