RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1202822 - QEMU SMRAM support for proper secure boot using OVMF
Summary: QEMU SMRAM support for proper secure boot using OVMF
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: qemu-kvm-rhev
Version: 7.1
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: rc
: ---
Assignee: Gerd Hoffmann
QA Contact: aihua liang
URL:
Whiteboard:
Depends On: 1227278
Blocks: 1086864 1202819 1304483 1305606 1313485
TreeView+ depends on / blocked
 
Reported: 2015-03-17 13:55 UTC by Ademar Reis
Modified: 2016-11-07 20:20 UTC (History)
9 users (show)

Fixed In Version: qemu-2.5
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1202825 1304483 (view as bug list)
Environment:
Last Closed: 2016-11-07 20:20:32 UTC
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2016:2673 0 normal SHIPPED_LIVE qemu-kvm-rhev bug fix and enhancement update 2016-11-08 01:06:13 UTC

Description Ademar Reis 2015-03-17 13:55:55 UTC 
From Laszlo:

QEMU should define and implement the location & size of SMRAM, and the method to lock & unlock it. As far as I know, TCG already has some kind of support. (Only TCG.)

There's been at least one upstream discussion about this:

http://news.gmane.org/find-root.php?message_id=20140428140102.GA7576@morn.localdomain

(Plus, messages in that thread reference other discussions.)

The current suggestion seems to be the 0xa0000-0xc0000 range, which I
think should be possible for i440fx as well.

However, the size of that range is only 128KB, and the SMM Core in edk2 needs at least 256KB - 4KB == 252KB.

(See SmmIplEntry() in "MdeModulePkg/Core/PiSmmCore/PiSmmIpl.c", and SmmInitializeMemoryServices() in "MdeModulePkg/Core/PiSmmCore/Pool.c".)

We might have to introduce something new under 4GB-2MB (ie. underneath the pflash chip(s)), but that will seriously complicate things for OVMF (messing with the memory layout is always a pain).

Alternatively, we might inquire on edk2-devel where the 252KB SMRAM requirement comes from. (The answer is probably that SMRAM is not only used for storing data, it hosts some privileged driver executables as well.)
Comment 1 Laszlo Ersek 2015-04-08 08:06:24 UTC 
So this is an even worse mess than I expected. I had an annoying feeling in the back of my mind, and after re-checking the following whitepaper, that annoyance seems to be justified:

  A Tour Beyond BIOS:
  Implementing UEFI Authenticated Variables in SMM with EDKII

In the overview section, it introduces the platform-independent, variable-related SMM drivers (all known to us). Then it says (emphasis mine):

    This driver runs in SMM and expects to have another SMM driver, such as
    the closed sourced SMM FVB (Firmware Volume Block) driver, in order to
    write to SPI NOR from SMRAM. The PCH or other IOH is programmed such that
    the write access to SPI NOR can only occur from SMM.

    [...]

    So today’s art includes SMM for isolated execution and volatile storage,
    with SMM-based access control for writes to the SPI NOR.

Under Thread Model, it says

    [...] software attacking where ring0 non-UEFI code can directly
    modify the flash region containing the authenticated variables poses
    another concern.

    [...]

    Many platforms today use SMM and SPI NOR write trapping to have isolated,
    access controlled usage of this persistent store.

The above has two implications.

First, in OVMF even the current pflash driver, OvmfPkg/QemuFlashFvbServicesRuntimeDxe/, has to be replaced.

Second, the pflash implementation in QEMU, hw/block/pflash_cfi01.c, needs to know (or needs to be able to know) about SMM, and reject writes unless in SMM. Perhaps this can be implemented with some well placed memory_region_*() calls.
Comment 2 Paolo Bonzini 2015-04-08 10:46:07 UTC 
> Second, the pflash implementation in QEMU, hw/block/pflash_cfi01.c, needs to 
> know (or needs to be able to know) about SMM, and reject writes unless in SMM. 
> Perhaps this can be implemented with some well placed memory_region_*() calls.

Luckily this was expected.  The plan is to use Peter Maydell's MemTxAttrs patches to implement this.

I didn't know that QemuFlashFvbServicesRuntimeDxe had to be replaced (or at least an SMM variant of it has to be added), though in retrospect it's not too surprising.
Comment 7 aihua liang 2016-08-11 06:39:14 UTC 
Has verified it, the problem not exist.

 Verified Environment:
   Kernel version: 3.10.0-488.el7.x86_64
   QEMU verison: qemu-img-rhev-2.6.0-14.el7.x86_64
   OVMF Version: OVMF-20160608-3.git988715a.el7.noarch

 Verified cmds:
/usr/libexec/qemu-kvm -name rhel7 \
-machine q35,accel=kvm,usb=off,vmport=off,smm=on \
-cpu SandyBridge \
-m 8192 \
-realtime mlock=off \
-smp 5 \
-uuid 1534fa42-4818-4493-9f67-eee5ba758385 \
-no-user-config -nodefaults \
-chardev socket,id=qmp_id_catch_monitor,path=/var/tmp/test1,server,nowait \
-mon chardev=qmp_id_catch_monitor,id=monitor,mode=control \
-no-hpet \
-boot menu=on,splash-time=12000 \
-vga qxl \
-monitor stdio \
-vnc 0:2 \
-netdev tap,id=hostnet10 \
-device virtio-net-pci,netdev=hostnet10,id=net10,mac=58:54:00:49:b2:5f \
-spice ipv4,port=5000,disable-ticketing \
-enable-kvm \
-global ICH9-LPC.disable_s3=0 \
-drive file=/usr/share/OVMF/OVMF_CODE.secboot.fd,if=pflash,format=raw,readonly=on \
-drive file=/usr/share/OVMF/OVMF_Client_VARS.fd,if=pflash,format=raw \
-device ahci,id=ahci \
-global driver=cfi.pflash01,property=secure,value=on \
-drive file=/home/73test/img/bug_v_secure.qcow2,if=none,id=drive-ide-3,media=disk,format=qcow2,cache=none,aio=native \
-device ide-drive,drive=drive-ide-3,id=ide3,bus=ahci.0,bootindex=0 \
-drive file=/home/kvm_autotest_root/iso/linux/RHEL-7.2-20151030.0-Server-x86_64-dvd1.iso,if=none,cache=none,snapshot=off,aio=native,media=cdrom,id=cdrom2 \
-device ide-cd,drive=cdrom2,id=ide-cd2,bus=ahci.1,bootindex=2 \
-drive file=/usr/share/OVMF/UefiShell.iso,if=none,cache=none,snapshot=off,aio=native,media=cdrom,id=cdrom3 \
-device ide-cd,drive=cdrom3,id=ide-cd3,bus=ahci.2,bootindex=1 \

 Verified Steps:
   Refer to bug 1308678.
Comment 9 errata-xmlrpc 2016-11-07 20:20:32 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-2673.html
Note You need to log in before you can comment on or make changes to this bug.