Bug 1308678 - clearly separate SB-less, SMM-less OVMF binary from SB+SMM OVMF binary
Summary: clearly separate SB-less, SMM-less OVMF binary from SB+SMM OVMF binary
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
Jiri Herrmann
Depends On: 1341733
Blocks: 1086864 1304483
TreeView+ depends on / blocked
Reported: 2016-02-15 17:43 UTC by Laszlo Ersek
Modified: 2016-11-04 08:39 UTC (History)
11 users (show)

Fixed In Version: ovmf-20160608-1.git988715a.el7
Doc Type: No Doc Update
Doc Text:
no doc update
Clone Of:
Last Closed: 2016-11-04 08:39:52 UTC

Attachments (Terms of Use)
ovmf log (99.37 KB, text/plain)
2016-05-31 02:07 UTC, Guo, Zhiyi
no flags Details
ovmf log retest (326.51 KB, text/plain)
2016-06-15 06:38 UTC, Guo, Zhiyi
no flags Details

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-02-15 17:43:51 UTC
*** Description of problem:

(1) In downstream (packaging) commit 10fd652b6f4a ("redhat: build separate
SMM and no-SMM binaries for OVMF"), the "OVMF_CODE.fd" file was replaced
with new files "OVMF_CODE.nosmm.fd" and "OVMF_CODE.smm.fd".

"OVMF_CODE.nosmm.fd" would keep the same functionality as before (Secure
Boot enabled, SMM disabled), while "OVMF_CODE.smm.fd" would be Secure Boot
Enabled plus SMM enabled.

Renaming "OVMF_CODE.fd" to "OVMF_CODE.nosmm.fd" was recognized as breaking
compatibility for existing guests. Nonetheless the breakage was thought
justified, because an SMM-less firmware binary (whose Secure Boot would not
be in fact secure) was not going to be supported in the long term anyway.
Exposing this fact to consumers as early as possible appeared to minimize
pain later on.

Since then, a number of points have been raised and tracked down in bug

(1a) Renaming OVMF_CODE.fd to anything else breaks compatibility not only
     for existing guests (which may have been justifiable), i.e., domain
     XMLs, but also for management tools that (a) hardcode the filename, (b)
     don't care for Secure Boot for the tasks they perform.

(1b) Removing the Secure Boot feature from the OVMF_CODE.fd binary solves
     the "invalid sense of security" problem that "OVMF_CODE.fd" has in
     RHEL-7.2 (i.e., SB enabled, but no SMM). However, this would break
     existing guests, because the SB-less and SB-enabled builds used to
     require binarily incompatible varstore formats.

(1c) Since July 2015 (upstream edk2 commit fa0737a839d0) however, this
     limitation no longer exists. The unified variable driver now
     distinguishes variable store *format* from authenticated variable
     support (= actual SB enablement). The authenticated variable store
     *format* is compatible with SB-less and SB-enabled builds alike. This
     allows us to disable SB in the prior OVMF build, and varstores of
     preexistent guests will continue to work. If they had SB actually
     enabled, it will be silently disabled.

Ultimately, disabling SB in the "OVMF_CODE.nosmm.fd" binary, and renaming it
back to "OVMF_CODE.fd", will have the following consequences:

- management applications continue to work

- existing guests continue to work

- SMM-less secure boot gets silently disabled for those guests that enabled
  it (enrolled keys etc), and becomes unavailable to new guests installed
  with "OVMF_CODE.fd". This is a long-term supportable configuration.

(2) Additionally, it has been proposed that "OVMF_CODE.smm.fd" (= the SB+SMM
build) be renamed so that "SMM" (an implementation detail) is replaced with
a reference to Secure Boot (the more well known UEFI feature). Hence the new
name for that binary should be "OVMF_CODE.secboot.fd".

(3) The last question is that of the varstore template. Due to (1b), the
build process of the SB-enabled vs. SB-disabled OVMF binary used to generate
binarily different varstore templates. Hence switching the build from
SB-enabled to SB-disabled would generate a different varstore template.

Although we could perfectly well provide a separate varstore template per
OVMF binary, this would complicate matters for the management layer. Since
the unified variable driver is compatible with both varstore formats,
regardless of SB enablement, we can reuse the authenticated format template
for the SB-less build as well. We don't even have to implement this in the
RPM build script, because the varstore generation has been simplified in
upstream edk2 commit d92eaabefbe0 ("OvmfPkg: simplify VARIABLE_STORE_HEADER
generation"); we should just backport that.

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


Comment 1 Laszlo Ersek 2016-02-16 11:17:44 UTC
How to test this:

The first part of the testing / setup happens *before* upgrading the OVMF
binary package to the version that has the fix for this bug.

(01) Verify that the "nvram" stanza in "/etc/libvirt/qemu.conf" looks as

       nvram = [

     If it doesn't look like this, modify it, and then restart libvirtd
     (systemctl restart libvirtd).

(02) Install a new OVMF virtual machine -- let's call it

     In virt-manager, in the last dialog, select "Customize configuration
     before install", and flip the Firmware selection from BIOS to UEFI.
     Proceed with the installation as usual. (Including the final boot into
     the freshly installed guest.)

(03) Install another new OVMF virtual machine -- let's call it

     Do the same as in step (02), but after the installation completes, and
     the installed guest has been booted up, there are other steps as well:

     (a) Shut down the VM.

     (b) Attach the ISO image "/usr/share/OVMF/UefiShell.iso" to the virtual
         machine. IDE or virtio-scsi CD-ROM are both okay.

         Make sure that the CD-ROM comes first in the boot order, and the
         main disk (virtio-blk, virtio-scsi, or IDE -- not relevant) comes

     (c) Boot the virtual machine. You will end up in the UEFI shell.
         Execute the following command:


         It should succeed. Then run:

           reset -s

     (d) Boot the virtual machine again. This time Fedora should be launched

         Log in to the virtual machine, and run the following command:

           dmesg | grep -i secure

         The output should contain "Secure Boot enabled".

     (e) Shut down the VM.

At this point, upgrade the OVMF package. Continue with the following steps:

(04) Boot the "Fedora-i440fx-no-secboot" virtual machine.

     Verify that it boots okay, and that the OpenSSL banner has disappeared
     from the TianoCore splash screen. Shut down the VM.

(05) Modify the configuration of the "Fedora-i440fx-almost-secboot" virtual
     machine: remove the CD-ROM with the "UefiShell.iso" image from the
     *boot order only* (do not remove the device or the image itself).

(06) Boot the "Fedora-i440fx-almost-secboot" VM.

     (a) Verify that it boots okay, and that the OpenSSL banner has
         disappeared from the TianoCore splash screen.

     (b) Log in to the guest, and repeat the command

           dmesg | grep -i secure

         The secure boot feature should *not* be reported.

     (c) Reboot the guest, and interrupt the boot process at the TianoCore
         splash screen. Navigate to "Boot Manager" | "EFI Internal Shell".
         This option should exist, and the UEFI shell should be launched.

     (d) Execute the following command:


         The command should run, but it should *fail* with the following

           error: GetVariable("SetupMode",
                  Not Found

     (e) Shut off the VM with the

           reset -s

         UEFI shell command.

At this point we have verified that a firmware binary has been preserved
under the previous pathname (/usr/share/OVMF/OVMF_CODE.fd), that the secure
boot feature has been removed from it, and that preexistent guests continue
working with it (except the secure boot aspects themselves, which is

The rest of the steps can be used optionally, to verify the secure boot
functionality as well. Please note that if you decide to do this, it will
incur some host dependencies:

- the host kernel must contain the fix for bug 1271404
- qemu-kvm-rhev must contain the fix for bug 1202822
- libvirt must contain the fix for bug 1304483

(07) Verify that the "nvram" stanza in "/etc/libvirt/qemu.conf" looks as

       nvram = [

     If it doesn't look like this, modify it, and then restart libvirtd
     (systemctl restart libvirtd).

(08) Install a new virtual machine, called "Fedora-q35-secboot".

     In virt-manager, in the last dialog, select "Customize configuration
     before install". Flip the machine type from i440fx to Q35, and *also*
     change the firmware type from BIOS to "Custom --

     (It is possible that virt-manager will call this a different name later

     Installation should complete, including the boot into the freshly
     installed guest.

(09) Repeat steps (a) through (e) from (03), for the "Fedora-q35-secboot"

     Note that at some points the Linux boot process may feel a bit slower.
     This is a consequence of the SMM feature in OVMF. Functionally it
     should have no impact.

Comment 4 Laszlo Ersek 2016-02-16 14:42:11 UTC
Actually, I think I can open up this bug to the grand public, with one clarification:

(In reply to Laszlo Ersek from comment #0)
> (1b) Removing the Secure Boot feature from the OVMF_CODE.fd binary solves
>      the "invalid sense of security" problem that "OVMF_CODE.fd" has in
>      RHEL-7.2 (i.e., SB enabled, but no SMM). [...]

This is a problem in name only, of course -- we had been aware of what "SB without SMM" meant; SB was enabled only for testing / development purposes, and OVMF was Tech Preview.

Comment 9 Laszlo Ersek 2016-03-17 15:05:19 UTC
The docs for this bug will be squashed into the relnotes for bug 1202819.

Comment 10 Laszlo Ersek 2016-04-20 17:12:14 UTC
Further changes are required for this bug; moving it back to ASSIGNED.

Namely, an agreement has been reached on virt-devel: "OVMF_CODE.fd" shall not be shipped at all.

This means that there will be no support for i440fx machine types.

Also, in comment 1, steps 01 through 06 are no longer relevant per se, and step 07 should be updated to remove the "OVMF_CODE.fd" line.

Comment 11 Laszlo Ersek 2016-04-20 17:13:24 UTC
Sorry, this hasn't FailedQA; it's a scope change that supersedes the earlier state of this bug. Removing FailedQA.

Comment 14 Guo, Zhiyi 2016-05-31 02:07:48 UTC
Created attachment 1163001 [details]
ovmf log

Package used:

qemu cmd line:
/usr/libexec/qemu-kvm -name fedora22-3 \
-machine pc-q35-rhel7.2.0,accel=kvm,usb=off,vmport=off,smm=on \
-cpu IvyBridge \
 -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/var/lib/libvirt/qemu/nvram/fedora22-3_VARS.fd,if=pflash,format=raw,unit=1 \
-m 2048 -realtime mlock=off  \
-smp 1,sockets=1,cores=1,threads=1 -uuid 9a69847b-ff96-41bc-8a66-ff96113a1da3 \
-nodefaults  -rtc base=utc,driftfix=slew \
-global driver=cfi.pflash01,property=secure,value=on \
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown \
-boot strict=on \
-device virtio-scsi-pci,id=scsi0 -device virtio-serial-pci,id=virtio-serial0 -drive file=/home/Fedora-q35-secboot.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 \
-drive file=/usr/share/OVMF/UefiShell.iso,if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
-spice port=5900,addr=,disable-ticketing,image-compression=off,seamless-migration=on \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16 -monitor stdio \
-global isa-debugcon.iobase=0x402 -debugcon file:/home/ovmf.log

Following steps from step (07), in step (03)(c), UEFI shell always stuck like:
info: SetupMode=1 SecureBoot=0 SecureBootEnable=0 CustomMode=0 VendorKeys=1

Attach debug log.

Comment 15 Guo, Zhiyi 2016-05-31 02:10:06 UTC
Hi Laszlo,

Could u look at this?

Comment 16 Laszlo Ersek 2016-05-31 11:19:35 UTC
Hello Zhiyi,

I'm looking into this. Meanwhile could you please provide your host's /proc/cpuinfo? Thanks. (I'm not clearing the NEEDINFO just yet.)

Comment 17 Guo, Zhiyi 2016-05-31 12:42:34 UTC
My host info, only present cpu0 here, cpu1-cpu7 are same as cpu0:
processor       : 0
vendor_id       : GenuineIntel
cpu family      : 6
model           : 58
model name      : Intel(R) Core(TM) i7-3770 CPU @ 3.40GHz
stepping        : 9
microcode       : 0x1b
cpu MHz         : 1670.117
cache size      : 8192 KB
physical id     : 0
siblings        : 8
core id         : 0
cpu cores       : 4
apicid          : 0
initial apicid  : 0
fpu             : yes
fpu_exception   : yes
cpuid level     : 13
wp              : yes
flags           : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc aperfmperf eagerfpu pni pclmulqdq dtes64 monitor ds_cpl vmx smx est tm2 ssse3 cx16 xtpr pdcm pcid sse4_1 sse4_2 x2apic popcnt tsc_deadline_timer aes xsave avx f16c rdrand lahf_lm ida arat epb pln pts dtherm tpr_shadow vnmi flexpriority ept vpid fsgsbase smep erms xsaveopt
bogomips        : 6784.88
clflush size    : 64
cache_alignment : 64
address sizes   : 36 bits physical, 48 bits virtual
power management:

Comment 18 Laszlo Ersek 2016-06-01 11:41:24 UTC
Regarding the issue reported in comment 14, I can reproduce it.

I've done a bunch of analyzing in the upstream thread <http://thread.gmane.org/gmane.comp.bios.edk2.devel/12864>, but I'm not finished yet. I've identified the lower-level symptoms of the bug, but I cannot explain why the symptoms exist.

I can also not tie the bug to any specific commit. I did bisect edk2 and I identified two commits: one that "introduces" the bug (and "causes" the issue in comment 14), and another that "fixes" the bug (makes it disappear, present in upstream only). However, those commits are not actually related to the symptoms, they just cause some perturbance in timing, or in something else that provokes / masks the symptoms. (For example, reverting the supposed "fix" on top of edk2 master doesn't make the symptoms reappear.)

If we rebased OVMF to current upstream edk2 (2f7b34b20842), then the symptoms would go away (they don't reproduce with upstream), but I wouldn't be able to tell what caused them originally, and what "fixed" them.

At the moment I can't even identify the culprit component (KVM, QEMU, OVMF) with certainty. Changing QEMU and KVM versions doesn't seem to make a difference (the symptoms reproduce with TCG even), while edk2 has specific tree *states* (not individual patches!) that trigger and mask the problem. This implies OVMF is the most likely culprit, but I've got no proof.

I'll leave the NEEDINFO in place for a bit longer.

Comment 19 Laszlo Ersek 2016-06-01 15:27:55 UTC
I found the bug (with some gentle hints from Paolo :)), and I have a fix for it as well (it is a tuneables bug in upstream too). The bug is independent from this RHBZ; it's just that the testing of this RHBZ triggered it.

I will file a new RHBZ (for OVMF) about it, and make it block this RHBZ. Once that RHBZ is fixed, QE can return to testing this RHBZ as well.

For now I am moving this RHBZ back to ASSIGNED. Once we have a new build, we can immediately move this RHBZ to MODIFIED (no additional patches needed here).

Thank you for the report, Zhiyi; you uncovered a nasty bug (SMM stack overflow).

Comment 21 Guo, Zhiyi 2016-06-14 02:28:43 UTC
Due to https://bugzilla.redhat.com/show_bug.cgi?id=1308678#c12, i440fx not support on ovmf,only test step (07) (08) (09)

Package used:

Install fedora with qemu cmd line, just like (08):
/usr/libexec/qemu-kvm -name fedora22-3 \
-machine q35,accel=kvm,usb=off,vmport=off,smm=on \
-cpu IvyBridge \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1 \
-m 2048 -realtime mlock=off  \
-smp 1,sockets=1,cores=1,threads=1 -uuid aa8e03b1-8953-450f-b63d-c1064b9e442d \
-nodefaults  -rtc base=utc,driftfix=slew \
-boot strict=on \
-global driver=cfi.pflash01,property=secure,value=on \
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown \
-device virtio-scsi-pci,id=scsi0 -drive file=/home/Fedora-Live-Workstation-x86_64-23-10.iso,if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
-device virtio-serial-pci,id=virtio-serial0 -drive file=/home/Fedora-q35-secboot-2.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=2 \
-spice port=5900,addr=,disable-ticketing,image-compression=off,seamless-migration=on \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16 -monitor stdio \
-global isa-debugcon.iobase=0x402 -debugcon file:/home/ovmf.log

Change iso from /home/Fedora-Live-Workstation-x86_64-23-10.iso to /usr/share/OVMF/UefiShell.iso and launch fedora guest, then do step as (09).After step (09), fedora guest is launched successfully and output from dmesg:
[root@dhcp-11-67 ~]#dmesg | grep -i secure
[    0.000000] Secure boot enabled

After 5 trials, all tests pass.

Comment 22 Guo, Zhiyi 2016-06-14 02:42:08 UTC
Hi Laszlo,
Retest the steps (07) (08) (09) and steps all pass. As we talked, this bug can verify 1202819 and 1271404 and 1202822 and 1341733, could u check my test result from https://bugzilla.redhat.com/show_bug.cgi?id=1308678#c21 and comment whether we can verify these bugs?

Guo, Zhiyi

Comment 23 Laszlo Ersek 2016-06-14 14:00:30 UTC
(1) Thanks for the testing, it looks good, except for one part:

  -drive file=/usr/share/OVMF/OVMF_VARS.fd,if=pflash,format=raw,unit=1

This option is incorrect. (And I think it makes sense to emphasize its incorrectnes at this point, because I assume QE will continue testing OVMF with direct qemu-kvm invocations, and this issue should be clarified once and for all.)

Namely, the unit=1 pflash drive is a read-write one. It is not read-only. This pflash drive contains the UEFI variable store for the virtual machine. It is a host side file that is private to the specific virtual machine (just as writeable hard disk images), and must not be shared between virtual machines.

So, what libvirt does is, whenever you create a new OVMF virtual machine, it creates a *copy* of "/usr/share/OVMF/OVMF_VARS.fd", when the VM is launched for the very first time. That copy is stored, on the host, under "/var/lib/libvirt/qemu/nvram/". And when the guest actually runs, the command line option is something like (for a guest called "ovmf.fedora"):

  -drive file=/var/lib/libvirt/qemu/nvram/ovmf.fedora.q35_VARS.fd,if=pflash,format=raw,unit=1

The point is, if you run an OVMF virtual machine directly with qemu-kvm, then this initial copying step falls on you. You must first create a copy of OVMF_VARS.fd for the given virtual machine, and then in all further invocations of QEMU, for the same virtual machine, you must pass that *copy* as the unit=1 pflash drive.

In my own QEMU test scripts, I have logic like this:

  # if the varstore does not exist for this VM yet, then copy it first from
  # the OVMF_VARS.fd template file
  if ! test -e my_varstore.fd; then
    cp -v /usr/share/OVMF/OVMF_VARS.fd my_varstore.fd

  # use the VM's own private varstore
  /usr/libexec/qemu-kvm ... \
    -drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
    -drive file=my_varstore.fd,if=pflash,format=raw,unit=1 \

- OVMF_CODE.secboot.fd is read-only and shared between VMs,
- OVMF_VARS.fd is also read-only, but never accessed by VMs. It is only used
  as a template file, by libvirt and by the human tester, for creating the
  VM's own, actual, private varstore file, before the first run.

If you pass the OVMF_VARS.fd template file directly to QEMU, as the unit=1 pflash drive, then two things can happen:

- if you run qemu-kvm as an unprivileged user, then the file will be mapped read-only, and UEFI variable services will be broken in the guest, in obscure ways

- if you run qemu-kvm as root, then the /usr/share/OVMF/OVMF_VARS.fd template file will be overwritten, which breaks packaging (--> it modifies a system-wide file, you can check it with "rpm --verify OVMF"). In order to recover from this, you have to uninstall and reinstall the OVMF package.

(The second could never happen with libvirtd: not only does libvirtd create the private varstore from the template, it also changes to UID "qemu", which has no permission to overwrite files under /usr/share/OVMF.)

(2) Another thing I've noticed is the bootindex / CD changes, between installation and installed startup. It is actually not necessary to change ISOs and bootindexes at all. For example, with the following scheme:

- system disk: bootindex=0
- UefiShell.iso: bootindex=1
- Fedora LiveCD: bootindex=2

you can test everything necessary, without touching the QEMU command line at all. Namely, at the very first boot, the system dsk will be empty, so it cannot be booted, and OVMF will skip over it. UefiShell.iso will be booted, and you will end up at the UEFI shell prompt. This is when you can run "EnrollDefaultKeys.efi", and the "reset -s" (or "reset -c", for rebooting) commands.

At the second boot, the system disk is still empty, so it will be skipped. UefiShell.iso will also be skipped, because the UEFI shell binary is not signed, but in the previous step, we have enabled secure boot. So, the third option, Fedora LiveCD will be booted (because that one is signed). This is when you install the guest to the system disk (already running in secure boot mode), and after installation, reboot the guest.

At the third boot, the system disk is populated, and the boot loader on it (shim.efi) is signed as well. So the installed Fedora OS will be booted (as option #0), and you can verify it is running in secure boot mode (dmesg).


(1) whenever running OVMF guests directly with /usr/libexec/qemu-kvm, please take care to copy the varstore template to a private varstore file first, and then pass the *copy* to the VM, as unit=1 pflash.

(2) It is possible to insert both the UefiShell.iso and the Fedora Live CDs at the same time (using two virtio-scsi CD-ROMs, for example), and employ bootindices such that you never have to modify the QEMU command line.

Remark (2) is just for your convenience, but remark (1) is important. I would like to request that you repeat the test, with (1) addressed. Then it will be fine to mark all of: bug 1202819, bug 1271404, bug 1202822, and bug 1341733 as VERIFIED. (Plus this one too.)

Before retesting, please be sure to reinstall the pristine OVMF package, because on your host, "/usr/share/OVMF/OVMF_VARS.fd" may have been overwritten already.


Comment 24 Laszlo Ersek 2016-06-14 14:06:41 UTC
Furthermore, please upload the ovmf debug log when your testing is complete, so that I can sanity-check a few things in it. Thank you!

Comment 25 Guo, Zhiyi 2016-06-15 06:38:05 UTC
Created attachment 1168166 [details]
ovmf log retest

Package used:
Before reinstall OVMF-20160608-1.git988715a.el7.noarch, execute:
[root@dhcp-11-59 ovmf]# rpm --verify OVMF 
..5....T.    /usr/share/OVMF/OVMF_VARS.fd
.....UG..    /usr/share/OVMF/UefiShell.iso
After reinstall, nothing out after rpm verify, ovmf package is clean.

qemu cmd used:
/usr/libexec/qemu-kvm -name fedora22-3 \
-machine q35,accel=kvm,usb=off,vmport=off,smm=on \
-cpu IvyBridge \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,unit=0,readonly=on \
-drive file=/home/zhguo/fedora_VARS.fd,if=pflash,format=raw,unit=1 \
-m 2048 -realtime mlock=off  \
-smp 1,sockets=1,cores=1,threads=1 -uuid aa8e03b1-8953-450f-b63d-c1064b9e442d \
-nodefaults  -rtc base=utc,driftfix=slew \
-boot strict=on \
-global driver=cfi.pflash01,property=secure,value=on \
-global kvm-pit.lost_tick_policy=discard -no-hpet -no-shutdown \
-device virtio-serial-pci,id=virtio-serial0 -drive file=/home/zhguo/Fedora-q35-secboot.qcow2,if=none,id=drive-virtio-disk0,format=qcow2 -device virtio-blk-pci,scsi=off,drive=drive-virtio-disk0,id=virtio-disk0,bootindex=0 \
-device virtio-scsi-pci,id=scsi0 -drive file=/usr/share/OVMF/UefiShell.iso,if=none,id=drive-scsi0-0-0-0,readonly=on,format=raw -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=0,drive=drive-scsi0-0-0-0,id=scsi0-0-0-0,bootindex=1 \
-device virtio-scsi-pci,id=scsi1 -drive file=/home/zhguo/Fedora-Live-Workstation-x86_64-23-10.iso,if=none,id=drive-scsi0-0-0-1,readonly=on,format=raw -device scsi-cd,bus=scsi0.0,channel=0,scsi-id=0,lun=1,drive=drive-scsi0-0-0-1,id=scsi0-0-0-1,bootindex=2 \
-spice port=5900,addr=,disable-ticketing,image-compression=off,seamless-migration=on \
-device qxl-vga,id=video0,ram_size=67108864,vram_size=67108864,vgamem_mb=16 -monitor stdio \
-global isa-debugcon.iobase=0x402 -debugcon file:/home/zhguo/ovmf.log

Run as unprivileged user and follow steps of (2) from https://bugzilla.redhat.com/show_bug.cgi?id=1308678#c23
, both steps are running following explain. After third boot, login and output from dmesg:
[root@dhcp-11-67 ~]#dmesg | grep -i secure
[    0.000000] Secure boot enabled

Attach ovmf log for check

Comment 26 Guo, Zhiyi 2016-06-15 06:40:24 UTC
Hi Laszlo,

Here is the latest result, please check!
Guo Zhiyi

Comment 27 Laszlo Ersek 2016-06-15 08:42:42 UTC
Hi Guo Zhiyi,

thanks for retesting, everything looks fine!

Please go ahead with the planned status changes for the bugzillas in question.


Comment 30 aihua liang 2016-09-07 11:19:35 UTC
Has verified, SB can work normally.

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 32 errata-xmlrpc 2016-11-04 08:39:52 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.