You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
2423 lines
105 KiB
2423 lines
105 KiB
2 years ago
|
Open Virtual Machine Firmware (OVMF) Status Report
|
||
|
|
July 2014 (with updates in August 2014 - January 2015)
|
||
|
|
|
||
|
|
Author: Laszlo Ersek <lersek@redhat.com>
|
||
|
|
Copyright (C) 2014-2015, Red Hat, Inc.
|
||
|
|
CC BY-SA 4.0 <http://creativecommons.org/licenses/by-sa/4.0/>
|
||
|
|
|
||
|
|
Abstract
|
||
|
|
--------
|
||
|
|
|
||
|
|
The Unified Extensible Firmware Interface (UEFI) is a specification that
|
||
|
|
defines a software interface between an operating system and platform firmware.
|
||
|
|
UEFI is designed to replace the Basic Input/Output System (BIOS) firmware
|
||
|
|
interface.
|
||
|
|
|
||
|
|
Hardware platform vendors have been increasingly adopting the UEFI
|
||
|
|
Specification to govern their boot firmware developments. OVMF (Open Virtual
|
||
|
|
Machine Firmware), a sub-project of Intel's EFI Development Kit II (edk2),
|
||
|
|
enables UEFI support for Ia32 and X64 Virtual Machines.
|
||
|
|
|
||
|
|
This paper reports on the status of the OVMF project, treats features and
|
||
|
|
limitations, gives end-user hints, and examines some areas in-depth.
|
||
|
|
|
||
|
|
Keywords: ACPI, boot options, CSM, edk2, firmware, flash, fw_cfg, KVM, memory
|
||
|
|
map, non-volatile variables, OVMF, PCD, QEMU, reset vector, S3, Secure Boot,
|
||
|
|
Smbios, SMM, TianoCore, UEFI, VBE shim, Virtio
|
||
|
|
|
||
|
|
Table of Contents
|
||
|
|
-----------------
|
||
|
|
|
||
|
|
- Motivation
|
||
|
|
- Scope
|
||
|
|
- Example qemu invocation
|
||
|
|
- Installation of OVMF guests with virt-manager and virt-install
|
||
|
|
- Supported guest operating systems
|
||
|
|
- Compatibility Support Module (CSM)
|
||
|
|
- Phases of the boot process
|
||
|
|
- Project structure
|
||
|
|
- Platform Configuration Database (PCD)
|
||
|
|
- Firmware image structure
|
||
|
|
- S3 (suspend to RAM and resume)
|
||
|
|
- A comprehensive memory map of OVMF
|
||
|
|
- Known Secure Boot limitations
|
||
|
|
- Variable store and LockBox in SMRAM
|
||
|
|
- Select features
|
||
|
|
- X64-specific reset vector for OVMF
|
||
|
|
- Client library for QEMU's firmware configuration interface
|
||
|
|
- Guest ACPI tables
|
||
|
|
- Guest SMBIOS tables
|
||
|
|
- Platform-specific boot policy
|
||
|
|
- Virtio drivers
|
||
|
|
- Platform Driver
|
||
|
|
- Video driver
|
||
|
|
- Afterword
|
||
|
|
|
||
|
|
Motivation
|
||
|
|
----------
|
||
|
|
|
||
|
|
OVMF extends the usual benefits of virtualization to UEFI. Reasons to use OVMF
|
||
|
|
include:
|
||
|
|
|
||
|
|
- Legacy-free guests. A UEFI-based environment eliminates dependencies on
|
||
|
|
legacy address spaces and devices. This is especially beneficial when used
|
||
|
|
with physically assigned devices where the legacy operating mode is
|
||
|
|
troublesome to support, ex. assigned graphics cards operating in legacy-free,
|
||
|
|
non-VGA mode in the guest.
|
||
|
|
|
||
|
|
- Future proof guests. The x86 market is steadily moving towards a legacy-free
|
||
|
|
platform and guest operating systems may eventually require a UEFI
|
||
|
|
environment. OVMF provides that next generation firmware support for such
|
||
|
|
applications.
|
||
|
|
|
||
|
|
- GUID partition tables (GPTs). MBR partition tables represent partition
|
||
|
|
offsets and sizes with 32-bit integers, in units of 512 byte sectors. This
|
||
|
|
limits the addressable portion of the disk to 2 TB. GPT represents logical
|
||
|
|
block addresses with 64 bits.
|
||
|
|
|
||
|
|
- Liberating boot loader binaries from residing in contested and poorly defined
|
||
|
|
space between the partition table and the partitions.
|
||
|
|
|
||
|
|
- Support for booting off disks (eg. pass-through physical SCSI devices) with a
|
||
|
|
4kB physical and logical sector size, i.e. which don't have 512-byte block
|
||
|
|
emulation.
|
||
|
|
|
||
|
|
- Development and testing of Secure Boot-related features in guest operating
|
||
|
|
systems. Although OVMF's Secure Boot implementation is currently not secure
|
||
|
|
against malicious UEFI drivers, UEFI applications, and guest kernels,
|
||
|
|
trusted guest code that only uses standard UEFI interfaces will find a valid
|
||
|
|
Secure Boot environment under OVMF, with working key enrollment and signature
|
||
|
|
validation. This enables development and testing of portable, Secure
|
||
|
|
Boot-related guest code.
|
||
|
|
|
||
|
|
- Presence of non-volatile UEFI variables. This furthers development and
|
||
|
|
testing of OS installers, UEFI boot loaders, and unique, dependent guest OS
|
||
|
|
features. For example, an efivars-backed pstore (persistent storage)
|
||
|
|
file system works under Linux.
|
||
|
|
|
||
|
|
- Altogether, a near production-level UEFI environment for virtual machines
|
||
|
|
when Secure Boot is not required.
|
||
|
|
|
||
|
|
Scope
|
||
|
|
-----
|
||
|
|
|
||
|
|
UEFI and especially Secure Boot have been topics fraught with controversy and
|
||
|
|
political activism. This paper sidesteps these aspects and strives to focus on
|
||
|
|
use cases, hands-on information for end users, and technical details.
|
||
|
|
|
||
|
|
Unless stated otherwise, the expression "X supports Y" means "X is technically
|
||
|
|
compatible with interfaces provided or required by Y". It does not imply
|
||
|
|
support as an activity performed by natural persons or companies.
|
||
|
|
|
||
|
|
We discuss the status of OVMF at a state no earlier than edk2 SVN revision
|
||
|
|
16158. The paper concentrates on upstream projects and communities, but
|
||
|
|
occasionally it pans out about OVMF as it is planned to be shipped (as
|
||
|
|
Technical Preview) in Red Hat Enterprise Linux 7.1. Such digressions are marked
|
||
|
|
with the [RHEL] margin notation.
|
||
|
|
|
||
|
|
Although other VMMs and accelerators are known to support (or plan to support)
|
||
|
|
OVMF to various degrees -- for example, VirtualBox, Xen, BHyVe --, we'll
|
||
|
|
emphasize OVMF on qemu/KVM, because QEMU and KVM have always been Red Hat's
|
||
|
|
focus wrt. OVMF.
|
||
|
|
|
||
|
|
The recommended upstream QEMU version is 2.1+. The recommended host Linux
|
||
|
|
kernel (KVM) version is 3.10+. The recommended QEMU machine type is
|
||
|
|
"qemu-system-x86_64 -M pc-i440fx-2.1" or later.
|
||
|
|
|
||
|
|
The term "TianoCore" is used interchangeably with "edk2" in this paper.
|
||
|
|
|
||
|
|
Example qemu invocation
|
||
|
|
-----------------------
|
||
|
|
|
||
|
|
The following commands give a quick foretaste of installing a UEFI operating
|
||
|
|
system on OVMF, relying only on upstream edk2 and qemu.
|
||
|
|
|
||
|
|
- Clone and build OVMF:
|
||
|
|
|
||
|
|
git clone https://github.com/tianocore/edk2.git
|
||
|
|
cd edk2
|
||
|
|
nice OvmfPkg/build.sh -a X64 -n $(getconf _NPROCESSORS_ONLN)
|
||
|
|
|
||
|
|
(Note that this ad-hoc build will not include the Secure Boot feature.)
|
||
|
|
|
||
|
|
- The build output file, "OVMF.fd", includes not only the executable firmware
|
||
|
|
code, but the non-volatile variable store as well. For this reason, make a
|
||
|
|
VM-specific copy of the build output (the variable store should be private to
|
||
|
|
the virtual machine):
|
||
|
|
|
||
|
|
cp Build/OvmfX64/DEBUG_GCC4?/FV/OVMF.fd fedora.flash
|
||
|
|
|
||
|
|
(The variable store and the firmware executable are also available in the
|
||
|
|
build output as separate files: "OVMF_VARS.fd" and "OVMF_CODE.fd". This
|
||
|
|
enables central management and updates of the firmware executable, while each
|
||
|
|
virtual machine can retain its own variable store.)
|
||
|
|
|
||
|
|
- Download a Fedora LiveCD:
|
||
|
|
|
||
|
|
wget https://dl.fedoraproject.org/pub/fedora/linux/releases/20/Live/x86_64/Fedora-Live-Xfce-x86_64-20-1.iso
|
||
|
|
|
||
|
|
- Create a virtual disk (qcow2 format, 20 GB in size):
|
||
|
|
|
||
|
|
qemu-img create -f qcow2 fedora.img 20G
|
||
|
|
|
||
|
|
- Create the following qemu wrapper script under the name "fedora.sh":
|
||
|
|
|
||
|
|
# Basic virtual machine properties: a recent i440fx machine type, KVM
|
||
|
|
# acceleration, 2048 MB RAM, two VCPUs.
|
||
|
|
OPTS="-M pc-i440fx-2.1 -enable-kvm -m 2048 -smp 2"
|
||
|
|
|
||
|
|
# The OVMF binary, including the non-volatile variable store, appears as a
|
||
|
|
# "normal" qemu drive on the host side, and it is exposed to the guest as a
|
||
|
|
# persistent flash device.
|
||
|
|
OPTS="$OPTS -drive if=pflash,format=raw,file=fedora.flash"
|
||
|
|
|
||
|
|
# The hard disk is exposed to the guest as a virtio-block device. OVMF has a
|
||
|
|
# driver stack that supports such a disk. We specify this disk as first boot
|
||
|
|
# option. OVMF recognizes the boot order specification.
|
||
|
|
OPTS="$OPTS -drive id=disk0,if=none,format=qcow2,file=fedora.img"
|
||
|
|
OPTS="$OPTS -device virtio-blk-pci,drive=disk0,bootindex=0"
|
||
|
|
|
||
|
|
# The Fedora installer disk appears as an IDE CD-ROM in the guest. This is
|
||
|
|
# the 2nd boot option.
|
||
|
|
OPTS="$OPTS -drive id=cd0,if=none,format=raw,readonly"
|
||
|
|
OPTS="$OPTS,file=Fedora-Live-Xfce-x86_64-20-1.iso"
|
||
|
|
OPTS="$OPTS -device ide-cd,bus=ide.1,drive=cd0,bootindex=1"
|
||
|
|
|
||
|
|
# The following setting enables S3 (suspend to RAM). OVMF supports S3
|
||
|
|
# suspend/resume.
|
||
|
|
OPTS="$OPTS -global PIIX4_PM.disable_s3=0"
|
||
|
|
|
||
|
|
# OVMF emits a number of info / debug messages to the QEMU debug console, at
|
||
|
|
# ioport 0x402. We configure qemu so that the debug console is indeed
|
||
|
|
# available at that ioport. We redirect the host side of the debug console to
|
||
|
|
# a file.
|
||
|
|
OPTS="$OPTS -global isa-debugcon.iobase=0x402 -debugcon file:fedora.ovmf.log"
|
||
|
|
|
||
|
|
# QEMU accepts various commands and queries from the user on the monitor
|
||
|
|
# interface. Connect the monitor with the qemu process's standard input and
|
||
|
|
# output.
|
||
|
|
OPTS="$OPTS -monitor stdio"
|
||
|
|
|
||
|
|
# A USB tablet device in the guest allows for accurate pointer tracking
|
||
|
|
# between the host and the guest.
|
||
|
|
OPTS="$OPTS -device piix3-usb-uhci -device usb-tablet"
|
||
|
|
|
||
|
|
# Provide the guest with a virtual network card (virtio-net).
|
||
|
|
#
|
||
|
|
# Normally, qemu provides the guest with a UEFI-conformant network driver
|
||
|
|
# from the iPXE project, in the form of a PCI expansion ROM. For this test,
|
||
|
|
# we disable the expansion ROM and allow OVMF's built-in virtio-net driver to
|
||
|
|
# take effect.
|
||
|
|
#
|
||
|
|
# On the host side, we use the SLIRP ("user") network backend, which has
|
||
|
|
# relatively low performance, but it doesn't require extra privileges from
|
||
|
|
# the user executing qemu.
|
||
|
|
OPTS="$OPTS -netdev id=net0,type=user"
|
||
|
|
OPTS="$OPTS -device virtio-net-pci,netdev=net0,romfile="
|
||
|
|
|
||
|
|
# A Spice QXL GPU is recommended as the primary VGA-compatible display
|
||
|
|
# device. It is a full-featured virtual video card, with great operating
|
||
|
|
# system driver support. OVMF supports it too.
|
||
|
|
OPTS="$OPTS -device qxl-vga"
|
||
|
|
|
||
|
|
qemu-system-x86_64 $OPTS
|
||
|
|
|
||
|
|
- Start the Fedora guest:
|
||
|
|
|
||
|
|
sh fedora.sh
|
||
|
|
|
||
|
|
- The above command can be used for both installation and later boots of the
|
||
|
|
Fedora guest.
|
||
|
|
|
||
|
|
- In order to verify basic OVMF network connectivity:
|
||
|
|
|
||
|
|
- Assuming that the non-privileged user running qemu belongs to group G
|
||
|
|
(where G is a numeric identifier), ensure as root on the host that the
|
||
|
|
group range in file "/proc/sys/net/ipv4/ping_group_range" includes G.
|
||
|
|
|
||
|
|
- As the non-privileged user, boot the guest as usual.
|
||
|
|
|
||
|
|
- On the TianoCore splash screen, press ESC.
|
||
|
|
|
||
|
|
- Navigate to Boot Manager | EFI Internal Shell
|
||
|
|
|
||
|
|
- In the UEFI Shell, issue the following commands:
|
||
|
|
|
||
|
|
ifconfig -s eth0 dhcp
|
||
|
|
ping A.B.C.D
|
||
|
|
|
||
|
|
where A.B.C.D is a public IPv4 address in dotted decimal notation that your
|
||
|
|
host can reach.
|
||
|
|
|
||
|
|
- Type "quit" at the (qemu) monitor prompt.
|
||
|
|
|
||
|
|
Installation of OVMF guests with virt-manager and virt-install
|
||
|
|
--------------------------------------------------------------
|
||
|
|
|
||
|
|
(1) Assuming OVMF has been installed on the host with the following files:
|
||
|
|
- /usr/share/OVMF/OVMF_CODE.fd
|
||
|
|
- /usr/share/OVMF/OVMF_VARS.fd
|
||
|
|
|
||
|
|
locate the "nvram" stanza in "/etc/libvirt/qemu.conf", and edit it as
|
||
|
|
follows:
|
||
|
|
|
||
|
|
nvram = [ "/usr/share/OVMF/OVMF_CODE.fd:/usr/share/OVMF/OVMF_VARS.fd" ]
|
||
|
|
|
||
|
|
(2) Restart libvirtd with your Linux distribution's service management tool;
|
||
|
|
for example,
|
||
|
|
|
||
|
|
systemctl restart libvirtd
|
||
|
|
|
||
|
|
(3) In virt-manager, proceed with the guest installation as usual:
|
||
|
|
- select File | New Virtual Machine,
|
||
|
|
- advance to Step 5 of 5,
|
||
|
|
- in Step 5, check "Customize configuration before install",
|
||
|
|
- click Finish;
|
||
|
|
- in the customization dialog, select Overview | Firmware, and choose UEFI,
|
||
|
|
- click Apply and Begin Installation.
|
||
|
|
|
||
|
|
(4) With virt-install:
|
||
|
|
|
||
|
|
LDR="loader=/usr/share/OVMF/OVMF_CODE.fd,loader_ro=yes,loader_type=pflash"
|
||
|
|
virt-install \
|
||
|
|
--name fedora20 \
|
||
|
|
--memory 2048 \
|
||
|
|
--vcpus 2 \
|
||
|
|
--os-variant fedora20 \
|
||
|
|
--boot hd,cdrom,$LDR \
|
||
|
|
--disk size=20 \
|
||
|
|
--disk path=Fedora-Live-Xfce-x86_64-20-1.iso,device=cdrom,bus=scsi
|
||
|
|
|
||
|
|
(5) A popular, distribution-independent, bleeding-edge OVMF package is
|
||
|
|
available under <https://www.kraxel.org/repos/>, courtesy of Gerd Hoffmann.
|
||
|
|
|
||
|
|
The "edk2.git-ovmf-x64" package provides the following files, among others:
|
||
|
|
- /usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd
|
||
|
|
- /usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd
|
||
|
|
|
||
|
|
When using this package, adapt steps (1) and (4) accordingly.
|
||
|
|
|
||
|
|
(6) Additionally, the "edk2.git-ovmf-x64" package seeks to simplify the
|
||
|
|
enablement of Secure Boot in a virtual machine (strictly for development
|
||
|
|
and testing purposes).
|
||
|
|
|
||
|
|
- Boot the virtual machine off the CD-ROM image called
|
||
|
|
"/usr/share/edk2.git/ovmf-x64/UefiShell.iso"; before or after installing
|
||
|
|
the main guest operating system.
|
||
|
|
|
||
|
|
- When the UEFI shell appears, issue the following commands:
|
||
|
|
|
||
|
|
EnrollDefaultKeys.efi
|
||
|
|
reset -s
|
||
|
|
|
||
|
|
- The EnrollDefaultKeys.efi utility enrolls the following keys:
|
||
|
|
|
||
|
|
- A static example X.509 certificate (CN=TestCommonName) as Platform Key
|
||
|
|
and first Key Exchange Key.
|
||
|
|
|
||
|
|
The private key matching this certificate has been destroyed (but you
|
||
|
|
shouldn't trust this statement).
|
||
|
|
|
||
|
|
- "Microsoft Corporation KEK CA 2011" as second Key Exchange Key
|
||
|
|
(SHA1: 31:59:0b:fd:89:c9:d7:4e:d0:87:df:ac:66:33:4b:39:31:25:4b:30).
|
||
|
|
|
||
|
|
- "Microsoft Windows Production PCA 2011" as first DB entry
|
||
|
|
(SHA1: 58:0a:6f:4c:c4:e4:b6:69:b9:eb:dc:1b:2b:3e:08:7b:80:d0:67:8d).
|
||
|
|
|
||
|
|
- "Microsoft Corporation UEFI CA 2011" as second DB entry
|
||
|
|
(SHA1: 46:de:f6:3b:5c:e6:1c:f8:ba:0d:e2:e6:63:9c:10:19:d0:ed:14:f3).
|
||
|
|
|
||
|
|
These keys suffice to boot released versions of popular Linux
|
||
|
|
distributions (through the shim.efi utility), and Windows 8 and Windows
|
||
|
|
Server 2012 R2, in Secure Boot mode.
|
||
|
|
|
||
|
|
Supported guest operating systems
|
||
|
|
---------------------------------
|
||
|
|
|
||
|
|
Upstream OVMF does not favor some guest operating systems over others for
|
||
|
|
political or ideological reasons. However, some operating systems are harder to
|
||
|
|
obtain and/or technically more difficult to support. The general expectation is
|
||
|
|
that recent UEFI OSes should just work. Please consult the "OvmfPkg/README"
|
||
|
|
file.
|
||
|
|
|
||
|
|
The following guest OSes were tested with OVMF:
|
||
|
|
- Red Hat Enterprise Linux 6
|
||
|
|
- Red Hat Enterprise Linux 7
|
||
|
|
- Fedora 18
|
||
|
|
- Fedora 19
|
||
|
|
- Fedora 20
|
||
|
|
- Windows Server 2008 R2 SP1
|
||
|
|
- Windows Server 2012
|
||
|
|
- Windows 8
|
||
|
|
|
||
|
|
Notes about Windows Server 2008 R2 (paraphrasing the "OvmfPkg/README" file):
|
||
|
|
|
||
|
|
- QEMU should be started with one of the "-device qxl-vga" and "-device VGA"
|
||
|
|
options.
|
||
|
|
|
||
|
|
- Only one video mode, 1024x768x32, is supported at OS runtime.
|
||
|
|
|
||
|
|
Please refer to the section about QemuVideoDxe (OVMF's built-in video driver)
|
||
|
|
for more details on this limitation.
|
||
|
|
|
||
|
|
- The qxl-vga video card is recommended ("-device qxl-vga"). After booting the
|
||
|
|
installed guest OS, select the video card in Device Manager, and upgrade the
|
||
|
|
video driver to the QXL XDDM one.
|
||
|
|
|
||
|
|
The QXL XDDM driver can be downloaded from
|
||
|
|
<http://www.spice-space.org/download.html>, under Guest | Windows binaries.
|
||
|
|
|
||
|
|
This driver enables additional graphics resolutions at OS runtime, and
|
||
|
|
provides S3 (suspend/resume) capability.
|
||
|
|
|
||
|
|
Notes about Windows Server 2012 and Windows 8:
|
||
|
|
|
||
|
|
- QEMU should be started with the "-device qxl-vga,revision=4" option (or a
|
||
|
|
later revision, if available).
|
||
|
|
|
||
|
|
- The guest OS's builtin video driver inherits the video mode / frame buffer
|
||
|
|
from OVMF. There's no way to change the resolution at OS runtime.
|
||
|
|
|
||
|
|
For this reason, a platform driver has been developed for OVMF, which allows
|
||
|
|
users to change the preferred video mode in the firmware. Please refer to the
|
||
|
|
section about PlatformDxe for details.
|
||
|
|
|
||
|
|
- It is recommended to upgrade the guest OS's video driver to the QXL WDDM one,
|
||
|
|
via Device Manager.
|
||
|
|
|
||
|
|
Binaries for the QXL WDDM driver can be found at
|
||
|
|
<http://people.redhat.com/~vrozenfe/qxlwddm> (pick a version greater than or
|
||
|
|
equal to 0.6), while the source code resides at
|
||
|
|
<https://github.com/vrozenfe/qxl-dod>.
|
||
|
|
|
||
|
|
This driver enables additional graphics resolutions at OS runtime, and
|
||
|
|
provides S3 (suspend/resume) capability.
|
||
|
|
|
||
|
|
Compatibility Support Module (CSM)
|
||
|
|
----------------------------------
|
||
|
|
|
||
|
|
Collaboration between SeaBIOS and OVMF developers has enabled SeaBIOS to be
|
||
|
|
built as a Compatibility Support Module, and OVMF to embed and use it.
|
||
|
|
|
||
|
|
Benefits of a SeaBIOS CSM include:
|
||
|
|
|
||
|
|
- The ability to boot legacy (non-UEFI) operating systems, such as legacy Linux
|
||
|
|
systems, Windows 7, OpenBSD 5.2, FreeBSD 8/9, NetBSD, DragonflyBSD, Solaris
|
||
|
|
10/11.
|
||
|
|
|
||
|
|
- Legacy (non-UEFI-compliant) PCI expansion ROMs, such as a VGA BIOS, mapped by
|
||
|
|
QEMU in emulated devices' ROM BARs, are loaded and executed by OVMF.
|
||
|
|
|
||
|
|
For example, this grants the Windows Server 2008 R2 SP1 guest's native,
|
||
|
|
legacy video driver access to all modes of all QEMU video cards.
|
||
|
|
|
||
|
|
Building the CSM target of the SeaBIOS source tree is out of scope for this
|
||
|
|
report. Additionally, upstream OVMF does not enable the CSM by default.
|
||
|
|
|
||
|
|
Interested users and developers should look for OVMF's "-D CSM_ENABLE"
|
||
|
|
build-time option, and check out the <https://www.kraxel.org/repos/> continuous
|
||
|
|
integration repository, which provides CSM-enabled OVMF builds.
|
||
|
|
|
||
|
|
[RHEL] The "OVMF_CODE.fd" firmware image made available on the Red Hat
|
||
|
|
Enterprise Linux 7.1 host does not include a Compatibility Support
|
||
|
|
Module, for the following reasons:
|
||
|
|
|
||
|
|
- Virtual machines running officially supported, legacy guest operating
|
||
|
|
systems should just use the standalone SeaBIOS firmware. Firmware
|
||
|
|
selection is flexible in virtualization, see eg. "Installation of OVMF
|
||
|
|
guests with virt-manager and virt-install" above.
|
||
|
|
|
||
|
|
- The 16-bit thunking interface between OVMF and SeaBIOS is very complex
|
||
|
|
and presents a large debugging and support burden, based on past
|
||
|
|
experience.
|
||
|
|
|
||
|
|
- Secure Boot is incompatible with CSM.
|
||
|
|
|
||
|
|
- Inter-project dependencies should be minimized whenever possible.
|
||
|
|
|
||
|
|
- Using the default QXL video card, the Windows 2008 R2 SP1 guest can be
|
||
|
|
installed with its built-in, legacy video driver. Said driver will
|
||
|
|
select the only available video mode, 1024x768x32. After installation,
|
||
|
|
the video driver can be upgraded to the full-featured QXL XDDM driver.
|
||
|
|
|
||
|
|
Phases of the boot process
|
||
|
|
--------------------------
|
||
|
|
|
||
|
|
The PI and UEFI specifications, and Intel's UEFI and EDK II Learning and
|
||
|
|
Development materials provide ample information on PI and UEFI concepts. The
|
||
|
|
following is an absolutely minimal, rough glossary that is included only to
|
||
|
|
help readers new to PI and UEFI understand references in later, OVMF-specific
|
||
|
|
sections. We defer heavily to the official specifications and the training
|
||
|
|
materials, and frequently quote them below.
|
||
|
|
|
||
|
|
A central concept to mention early is the GUID -- globally unique identifier. A
|
||
|
|
GUID is a 128-bit number, written as XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX,
|
||
|
|
where each X stands for a hexadecimal nibble. GUIDs are used to name everything
|
||
|
|
in PI and in UEFI. Programmers introduce new GUIDs with the "uuidgen" utility,
|
||
|
|
and standards bodies standardize well-known services by positing their GUIDs.
|
||
|
|
|
||
|
|
The boot process is roughly divided in the following phases:
|
||
|
|
|
||
|
|
- Reset vector code.
|
||
|
|
|
||
|
|
- SEC: Security phase. This phase is the root of firmware integrity.
|
||
|
|
|
||
|
|
- PEI: Pre-EFI Initialization. This phase performs "minimal processor, chipset
|
||
|
|
and platform configuration for the purpose of discovering memory". Modules in
|
||
|
|
PEI collectively save their findings about the platform in a list of HOBs
|
||
|
|
(hand-off blocks).
|
||
|
|
|
||
|
|
When developing PEI code, the Platform Initialization (PI) specification
|
||
|
|
should be consulted.
|
||
|
|
|
||
|
|
- DXE: Driver eXecution Environment, pronounced as "Dixie". This "is the phase
|
||
|
|
where the bulk of the booting occurs: devices are enumerated and initialized,
|
||
|
|
UEFI services are supported, and protocols and drivers are implemented. Also,
|
||
|
|
the tables that create the UEFI interface are produced".
|
||
|
|
|
||
|
|
On the PEI/DXE boundary, the HOBs produced by PEI are consumed. For example,
|
||
|
|
this is how the memory space map is configured initially.
|
||
|
|
|
||
|
|
- BDS: Boot Device Selection. It is "responsible for determining how and where
|
||
|
|
you want to boot the operating system".
|
||
|
|
|
||
|
|
When developing DXE and BDS code, it is mainly the UEFI specification that
|
||
|
|
should be consulted. When speaking about DXE, BDS is frequently considered to
|
||
|
|
be a part of it.
|
||
|
|
|
||
|
|
The following concepts are tied to specific boot process phases:
|
||
|
|
|
||
|
|
- PEIM: a PEI Module (pronounced "PIM"). A binary module running in the PEI
|
||
|
|
phase, consuming some PPIs and producing other PPIs, and producing HOBs.
|
||
|
|
|
||
|
|
- PPI: PEIM-to-PEIM interface. A structure of function pointers and related
|
||
|
|
data members that establishes a PEI service, or an instance of a PEI service.
|
||
|
|
PPIs are identified by GUID.
|
||
|
|
|
||
|
|
An example is EFI_PEI_S3_RESUME2_PPI (6D582DBC-DB85-4514-8FCC-5ADF6227B147).
|
||
|
|
|
||
|
|
- DXE driver: a binary module running in the DXE and BDS phases, consuming some
|
||
|
|
protocols and producing other protocols.
|
||
|
|
|
||
|
|
- Protocol: A structure of function pointers and related data members that
|
||
|
|
establishes a DXE service, or an instance of a DXE service. Protocols are
|
||
|
|
identified by GUID.
|
||
|
|
|
||
|
|
An example is EFI_BLOCK_IO_PROTOCOL (964E5B21-6459-11D2-8E39-00A0C969723B).
|
||
|
|
|
||
|
|
- Architectural protocols: a set of standard protocols that are foundational to
|
||
|
|
the working of a UEFI system. Each architectural protocol has at most one
|
||
|
|
instance. Architectural protocols are implemented by a subset of DXE drivers.
|
||
|
|
DXE drivers explicitly list the set of protocols (including architectural
|
||
|
|
protocols) that they need to work. UEFI drivers can only be loaded once all
|
||
|
|
architectural protocols have become available during the DXE phase.
|
||
|
|
|
||
|
|
An example is EFI_VARIABLE_WRITE_ARCH_PROTOCOL
|
||
|
|
(6441F818-6362-4E44-B570-7DBA31DD2453).
|
||
|
|
|
||
|
|
Project structure
|
||
|
|
-----------------
|
||
|
|
|
||
|
|
The term "OVMF" usually denotes the project (community and development effort)
|
||
|
|
that provide and maintain the subject matter UEFI firmware for virtual
|
||
|
|
machines. However the term is also frequently applied to the firmware binary
|
||
|
|
proper that a virtual machine executes.
|
||
|
|
|
||
|
|
OVMF emerges as a compilation of several modules from the edk2 source
|
||
|
|
repository. "edk2" stands for EFI Development Kit II; it is a "modern,
|
||
|
|
feature-rich, cross-platform firmware development environment for the UEFI and
|
||
|
|
PI specifications".
|
||
|
|
|
||
|
|
The composition of OVMF is dictated by the following build control files:
|
||
|
|
|
||
|
|
OvmfPkg/OvmfPkgIa32.dsc
|
||
|
|
OvmfPkg/OvmfPkgIa32.fdf
|
||
|
|
|
||
|
|
OvmfPkg/OvmfPkgIa32X64.dsc
|
||
|
|
OvmfPkg/OvmfPkgIa32X64.fdf
|
||
|
|
|
||
|
|
OvmfPkg/OvmfPkgX64.dsc
|
||
|
|
OvmfPkg/OvmfPkgX64.fdf
|
||
|
|
|
||
|
|
The format of these files is described in the edk2 DSC and FDF specifications.
|
||
|
|
Roughly, the DSC file determines:
|
||
|
|
- library instance resolutions for library class requirements presented by the
|
||
|
|
modules to be compiled,
|
||
|
|
- the set of modules to compile.
|
||
|
|
|
||
|
|
The FDF file roughly determines:
|
||
|
|
- what binary modules (compilation output files, precompiled binaries, graphics
|
||
|
|
image files, verbatim binary sections) to include in the firmware image,
|
||
|
|
- how to lay out the firmware image.
|
||
|
|
|
||
|
|
The Ia32 flavor of these files builds a firmware where both PEI and DXE phases
|
||
|
|
are 32-bit. The Ia32X64 flavor builds a firmware where the PEI phase consists
|
||
|
|
of 32-bit modules, and the DXE phase is 64-bit. The X64 flavor builds a purely
|
||
|
|
64-bit firmware.
|
||
|
|
|
||
|
|
The word size of the DXE phase must match the word size of the runtime OS -- a
|
||
|
|
32-bit DXE can't cooperate with a 64-bit OS, and a 64-bit DXE can't work a
|
||
|
|
32-bit OS.
|
||
|
|
|
||
|
|
OVMF pulls together modules from across the edk2 tree. For example:
|
||
|
|
|
||
|
|
- common drivers and libraries that are platform independent are usually
|
||
|
|
located under MdeModulePkg and MdePkg,
|
||
|
|
|
||
|
|
- common but hardware-specific drivers and libraries that match QEMU's
|
||
|
|
pc-i440fx-* machine type are pulled in from IntelFrameworkModulePkg,
|
||
|
|
PcAtChipsetPkg and UefiCpuPkg,
|
||
|
|
|
||
|
|
- the platform independent UEFI Shell is built from ShellPkg,
|
||
|
|
|
||
|
|
- OvmfPkg includes drivers and libraries that are useful for virtual machines
|
||
|
|
and may or may not be specific to QEMU's pc-i440fx-* machine type.
|
||
|
|
|
||
|
|
Platform Configuration Database (PCD)
|
||
|
|
-------------------------------------
|
||
|
|
|
||
|
|
Like the "Phases of the boot process" section, this one introduces a concept in
|
||
|
|
very raw form. We defer to the PCD related edk2 specifications, and we won't
|
||
|
|
discuss implementation details here. Our purpose is only to offer the reader a
|
||
|
|
usable (albeit possibly inaccurate) definition, so that we can refer to PCDs
|
||
|
|
later on.
|
||
|
|
|
||
|
|
Colloquially, when we say "PCD", we actually mean "PCD entry"; that is, an
|
||
|
|
entry stored in the Platform Configuration Database.
|
||
|
|
|
||
|
|
The Platform Configuration Database is
|
||
|
|
- a firmware-wide
|
||
|
|
- name-value store
|
||
|
|
- of scalars and buffers
|
||
|
|
- where each entry may be
|
||
|
|
- build-time constant, or
|
||
|
|
- run-time dynamic, or
|
||
|
|
- theoretically, a middle option: patchable in the firmware file itself,
|
||
|
|
using a dedicated tool. (OVMF does not utilize externally patchable
|
||
|
|
entries.)
|
||
|
|
|
||
|
|
A PCD entry is declared in the DEC file of the edk2 top-level Package directory
|
||
|
|
whose modules (drivers and libraries) are the primary consumers of the PCD
|
||
|
|
entry. (See for example OvmfPkg/OvmfPkg.dec). Basically, a PCD in a DEC file
|
||
|
|
exposes a simple customization point.
|
||
|
|
|
||
|
|
Interest in a PCD entry is communicated to the build system by naming the PCD
|
||
|
|
entry in the INF file of the interested module (application, driver or
|
||
|
|
library). The module may read and -- dependent on the PCD entry's category --
|
||
|
|
write the PCD entry.
|
||
|
|
|
||
|
|
Let's investigate the characteristics of the Database and the PCD entries.
|
||
|
|
|
||
|
|
- Firmware-wide: technically, all modules may access all entries they are
|
||
|
|
interested in, assuming they advertise their interest in their INF files.
|
||
|
|
With careful design, PCDs enable inter-driver propagation of (simple) system
|
||
|
|
configuration. PCDs are available in both PEI and DXE.
|
||
|
|
|
||
|
|
(UEFI drivers meant to be portable (ie. from third party vendors) are not
|
||
|
|
supposed to use PCDs, since PCDs qualify internal to the specific edk2
|
||
|
|
firmware in question.)
|
||
|
|
|
||
|
|
- Name-value store of scalars and buffers: each PCD has a symbolic name, and a
|
||
|
|
fixed scalar type (UINT16, UINT32 etc), or VOID* for buffers. Each PCD entry
|
||
|
|
belongs to a namespace, where a namespace is (obviously) a GUID, defined in
|
||
|
|
the DEC file.
|
||
|
|
|
||
|
|
- A DEC file can permit several categories for a PCD:
|
||
|
|
- build-time constant ("FixedAtBuild"),
|
||
|
|
- patchable in the firmware image ("PatchableInModule", unused in OVMF),
|
||
|
|
- runtime modifiable ("Dynamic").
|
||
|
|
|
||
|
|
The platform description file (DSC) of a top-level Package directory may choose
|
||
|
|
the exact category for a given PCD entry that its modules wish to use, and
|
||
|
|
assign a default (or constant) initial value to it.
|
||
|
|
|
||
|
|
In addition, the edk2 build system too can initialize PCD entries to values
|
||
|
|
that it calculates while laying out the flash device image. Such PCD
|
||
|
|
assignments are described in the FDF control file.
|
||
|
|
|
||
|
|
Firmware image structure
|
||
|
|
------------------------
|
||
|
|
|
||
|
|
(We assume the common X64 choice for both PEI and DXE, and the default DEBUG
|
||
|
|
build target.)
|
||
|
|
|
||
|
|
The OvmfPkg/OvmfPkgX64.fdf file defines the following layout for the flash
|
||
|
|
device image "OVMF.fd":
|
||
|
|
|
||
|
|
Description Compression type Size
|
||
|
|
------------------------------ ---------------------- -------
|
||
|
|
Non-volatile data storage open-coded binary data 128 KB
|
||
|
|
Variable store 56 KB
|
||
|
|
Event log 4 KB
|
||
|
|
Working block 4 KB
|
||
|
|
Spare area 64 KB
|
||
|
|
|
||
|
|
FVMAIN_COMPACT uncompressed 1712 KB
|
||
|
|
FV Firmware File System file LZMA compressed
|
||
|
|
PEIFV uncompressed 896 KB
|
||
|
|
individual PEI modules uncompressed
|
||
|
|
DXEFV uncompressed 8192 KB
|
||
|
|
individual DXE modules uncompressed
|
||
|
|
|
||
|
|
SECFV uncompressed 208 KB
|
||
|
|
SEC driver
|
||
|
|
reset vector code
|
||
|
|
|
||
|
|
The top-level image consists of three regions (three firmware volumes):
|
||
|
|
- non-volatile data store (128 KB),
|
||
|
|
- main firmware volume (FVMAIN_COMPACT, 1712 KB),
|
||
|
|
- firmware volume containing the reset vector code and the SEC phase code (208
|
||
|
|
KB).
|
||
|
|
|
||
|
|
In total, the OVMF.fd file has size 128 KB + 1712 KB + 208 KB == 2 MB.
|
||
|
|
|
||
|
|
(1) The firmware volume with non-volatile data store (128 KB) has the following
|
||
|
|
internal structure, in blocks of 4 KB:
|
||
|
|
|
||
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ L: event log
|
||
|
|
LIVE | varstore |L|W| W: working block
|
||
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
|
|
||
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
|
SPARE | |
|
||
|
|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|
||
|
|
|
||
|
|
The first half of this firmware volume is "live", while the second half is
|
||
|
|
"spare". The spare half is important when the variable driver reclaims
|
||
|
|
unused storage and reorganizes the variable store.
|
||
|
|
|
||
|
|
The live half dedicates 14 blocks (56 KB) to the variable store itself. On
|
||
|
|
top of those, one block is set aside for an event log, and one block is
|
||
|
|
used as the working block of the fault tolerant write protocol. Fault
|
||
|
|
tolerant writes are used to recover from an occasional (virtual) power loss
|
||
|
|
during variable updates.
|
||
|
|
|
||
|
|
The blocks in this firmware volume are accessed, in stacking order from
|
||
|
|
least abstract to most abstract, by:
|
||
|
|
|
||
|
|
- EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL (provided by
|
||
|
|
OvmfPkg/QemuFlashFvbServicesRuntimeDxe),
|
||
|
|
|
||
|
|
- EFI_FAULT_TOLERANT_WRITE_PROTOCOL (provided by
|
||
|
|
MdeModulePkg/Universal/FaultTolerantWriteDxe),
|
||
|
|
|
||
|
|
- architectural protocols instrumental to the runtime UEFI variable
|
||
|
|
services:
|
||
|
|
- EFI_VARIABLE_ARCH_PROTOCOL,
|
||
|
|
- EFI_VARIABLE_WRITE_ARCH_PROTOCOL.
|
||
|
|
|
||
|
|
In a non-secure boot build, the DXE driver providing these architectural
|
||
|
|
protocols is MdeModulePkg/Universal/Variable/RuntimeDxe. In a secure boot
|
||
|
|
build, where authenticated variables are available, the DXE driver
|
||
|
|
offering these protocols is SecurityPkg/VariableAuthenticated/RuntimeDxe.
|
||
|
|
|
||
|
|
(2) The main firmware volume (FVMAIN_COMPACT, 1712 KB) embeds further firmware
|
||
|
|
volumes. The outermost layer is a Firmware File System (FFS), carrying a
|
||
|
|
single file. This file holds an LZMA-compressed section, which embeds two
|
||
|
|
firmware volumes: PEIFV (896 KB) with PEIMs, and DXEFV (8192 KB) with DXE
|
||
|
|
and UEFI drivers.
|
||
|
|
|
||
|
|
This scheme enables us to build 896 KB worth of PEI drivers and 8192 KB
|
||
|
|
worth of DXE and UEFI drivers, compress them all with LZMA in one go, and
|
||
|
|
store the compressed result in 1712 KB, saving room in the flash device.
|
||
|
|
|
||
|
|
(3) The SECFV firmware volume (208 KB) is not compressed. It carries the
|
||
|
|
"volume top file" with the reset vector code, to end at 4 GB in
|
||
|
|
guest-physical address space, and the SEC phase driver (OvmfPkg/Sec).
|
||
|
|
|
||
|
|
The last 16 bytes of the volume top file (mapped directly under 4 GB)
|
||
|
|
contain a NOP slide and a jump instruction. This is where QEMU starts
|
||
|
|
executing the firmware, at address 0xFFFF_FFF0. The reset vector and the
|
||
|
|
SEC driver run from flash directly.
|
||
|
|
|
||
|
|
The SEC driver locates FVMAIN_COMPACT in the flash, and decompresses the
|
||
|
|
main firmware image to RAM. The rest of OVMF (PEI, DXE, BDS phases) run
|
||
|
|
from RAM.
|
||
|
|
|
||
|
|
As already mentioned, the OVMF.fd file is mapped by qemu's
|
||
|
|
"hw/block/pflash_cfi01.c" device just under 4 GB in guest-physical address
|
||
|
|
space, according to the command line option
|
||
|
|
|
||
|
|
-drive if=pflash,format=raw,file=fedora.flash
|
||
|
|
|
||
|
|
(refer to the Example qemu invocation). This is a "ROMD device", which can
|
||
|
|
switch out of "ROMD mode" and back into it.
|
||
|
|
|
||
|
|
Namely, in the default ROMD mode, the guest-physical address range backed by
|
||
|
|
the flash device reads and executes as ROM (it does not trap from KVM to QEMU).
|
||
|
|
The first write access in this mode traps to QEMU, and flips the device out of
|
||
|
|
ROMD mode.
|
||
|
|
|
||
|
|
In non-ROMD mode, the flash chip is programmed by storing CFI (Common Flash
|
||
|
|
Interface) command values at the flash-covered addresses; both reads and writes
|
||
|
|
trap to QEMU, and the flash contents are modified and synchronized to the
|
||
|
|
host-side file. A special CFI command flips the flash device back to ROMD mode.
|
||
|
|
|
||
|
|
Qemu implements the above based on the KVM_CAP_READONLY_MEM / KVM_MEM_READONLY
|
||
|
|
KVM features, and OVMF puts it to use in its EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL
|
||
|
|
implementation, under "OvmfPkg/QemuFlashFvbServicesRuntimeDxe".
|
||
|
|
|
||
|
|
IMPORTANT: Never pass OVMF.fd to qemu with the -bios option. That option maps
|
||
|
|
the firmware image as ROM into the guest's address space, and forces OVMF to
|
||
|
|
emulate non-volatile variables with a fallback driver that is bound to have
|
||
|
|
insufficient and confusing semantics.
|
||
|
|
|
||
|
|
The 128 KB firmware volume with the variable store, discussed under (1), is
|
||
|
|
also built as a separate host-side file, named "OVMF_VARS.fd". The "rest" is
|
||
|
|
built into a third file, "OVMF_CODE.fd", which is only 1920 KB in size. The
|
||
|
|
variable store is mapped into its usual location, at 4 GB - 2 MB = 0xFFE0_0000,
|
||
|
|
through the following qemu options:
|
||
|
|
|
||
|
|
-drive if=pflash,format=raw,readonly,file=OVMF_CODE.fd \
|
||
|
|
-drive if=pflash,format=raw,file=fedora.varstore.fd
|
||
|
|
|
||
|
|
This way qemu configures two flash chips consecutively, with start addresses
|
||
|
|
growing downwards, which is transparent to OVMF.
|
||
|
|
|
||
|
|
[RHEL] Red Hat Enterprise Linux 7.1 ships a Secure Boot-enabled, X64, DEBUG
|
||
|
|
firmware only. Furthermore, only the split files ("OVMF_VARS.fd" and
|
||
|
|
"OVMF_CODE.fd") are available.
|
||
|
|
|
||
|
|
S3 (suspend to RAM and resume)
|
||
|
|
------------------------------
|
||
|
|
|
||
|
|
As noted in Example qemu invocation, the
|
||
|
|
|
||
|
|
-global PIIX4_PM.disable_s3=0
|
||
|
|
|
||
|
|
command line option tells qemu and OVMF if the user would like to enable S3
|
||
|
|
support. (This is corresponds to the /domain/pm/suspend-to-mem/@enabled libvirt
|
||
|
|
domain XML attribute.)
|
||
|
|
|
||
|
|
Implementing / orchestrating S3 was a considerable community effort in OVMF. A
|
||
|
|
detailed description exceeds the scope of this report; we only make a few
|
||
|
|
statements.
|
||
|
|
|
||
|
|
(1) S3-related PPIs and protocols are well documented in the PI specification.
|
||
|
|
|
||
|
|
(2) Edk2 contains most modules that are needed to implement S3 on a given
|
||
|
|
platform. One abstraction that is central to the porting / extending of the
|
||
|
|
S3-related modules to a new platform is the LockBox library interface,
|
||
|
|
which a specific platform can fill in by implementing its own LockBox
|
||
|
|
library instance.
|
||
|
|
|
||
|
|
The LockBox library provides a privileged name-value store (to be addressed
|
||
|
|
by GUIDs). The privilege separation stretches between the firmware and the
|
||
|
|
operating system. That is, the S3-related machinery of the firmware saves
|
||
|
|
some items in the LockBox securely, under well-known GUIDs, before booting
|
||
|
|
the operating system. During resume (which is a form of warm reset), the
|
||
|
|
firmware is activated again, and retrieves items from the LockBox. Before
|
||
|
|
jumping to the OS's resume vector, the LockBox is secured again.
|
||
|
|
|
||
|
|
We'll return to this later when we separately discuss SMRAM and SMM.
|
||
|
|
|
||
|
|
(3) During resume, the DXE and later phases are never reached; only the reset
|
||
|
|
vector, and the SEC and PEI phases of the firmware run. The platform is
|
||
|
|
supposed to detect a resume in progress during PEI, and to store that fact
|
||
|
|
in the BootMode field of the Phase Handoff Information Table (PHIT) HOB.
|
||
|
|
OVMF keys this off the CMOS, see OvmfPkg/PlatformPei.
|
||
|
|
|
||
|
|
At the end of PEI, the DXE IPL PEIM (Initial Program Load PEI Module, see
|
||
|
|
MdeModulePkg/Core/DxeIplPeim) examines the Boot Mode, and if it says "S3
|
||
|
|
resume in progress", then the IPL branches to the PEIM that exports
|
||
|
|
EFI_PEI_S3_RESUME2_PPI (provided by UefiCpuPkg/Universal/Acpi/S3Resume2Pei)
|
||
|
|
rather than loading the DXE core.
|
||
|
|
|
||
|
|
S3Resume2Pei executes the technical steps of the resumption, relying on the
|
||
|
|
contents of the LockBox.
|
||
|
|
|
||
|
|
(4) During first boot (or after a normal platform reset), when DXE does run,
|
||
|
|
hardware drivers in the DXE phase are encouraged to "stash" their hardware
|
||
|
|
configuration steps (eg. accesses to PCI config space, I/O ports, memory
|
||
|
|
mapped addresses, and so on) in a centrally maintained, so called "S3 boot
|
||
|
|
script". Hardware accesses are represented with opcodes of a special binary
|
||
|
|
script language.
|
||
|
|
|
||
|
|
This boot script is to be replayed during resume, by S3Resume2Pei. The
|
||
|
|
general goal is to bring back hardware devices -- which have been powered
|
||
|
|
off during suspend -- to their original after-first-boot state, and in
|
||
|
|
particular, to do so quickly.
|
||
|
|
|
||
|
|
At the moment, OVMF saves only one opcode in the S3 resume boot script: an
|
||
|
|
INFORMATION opcode, with contents 0xDEADBEEF (in network byte order). The
|
||
|
|
consensus between Linux developers seems to be that boot firmware is only
|
||
|
|
responsible for restoring basic chipset state, which OVMF does during PEI
|
||
|
|
anyway, independently of S3 vs. normal reset. (One example is the power
|
||
|
|
management registers of the i440fx chipset.) Device and peripheral state is
|
||
|
|
the responsibility of the runtime operating system.
|
||
|
|
|
||
|
|
Although an experimental OVMF S3 boot script was at one point captured for
|
||
|
|
the virtual Cirrus VGA card, such a boot script cannot follow eg. video
|
||
|
|
mode changes effected by the OS. Hence the operating system can never avoid
|
||
|
|
restoring device state, and most Linux display drivers (eg. stdvga, QXL)
|
||
|
|
already cover S3 resume fully.
|
||
|
|
|
||
|
|
The XDDM and WDDM driver models used under Windows OSes seem to recognize
|
||
|
|
this notion of runtime OS responsibility as well. (See the list of OSes
|
||
|
|
supported by OVMF in a separate section.)
|
||
|
|
|
||
|
|
(5) The S3 suspend/resume data flow in OVMF is included here tersely, for
|
||
|
|
interested developers.
|
||
|
|
|
||
|
|
(a) BdsLibBootViaBootOption()
|
||
|
|
EFI_ACPI_S3_SAVE_PROTOCOL [AcpiS3SaveDxe]
|
||
|
|
- saves ACPI S3 Context to LockBox ---------------------+
|
||
|
|
(including FACS address -- FACS ACPI table |
|
||
|
|
contains OS waking vector) |
|
||
|
|
|
|
||
|
|
- prepares boot script: |
|
||
|
|
EFI_S3_SAVE_STATE_PROTOCOL.Write() [S3SaveStateDxe] |
|
||
|
|
S3BootScriptLib [PiDxeS3BootScriptLib] |
|
||
|
|
- opcodes & arguments are saved in NVS. --+ |
|
||
|
|
| |
|
||
|
|
- issues a notification by installing | |
|
||
|
|
EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL | |
|
||
|
|
| |
|
||
|
|
(b) EFI_S3_SAVE_STATE_PROTOCOL [S3SaveStateDxe] | |
|
||
|
|
S3BootScriptLib [PiDxeS3BootScriptLib] | |
|
||
|
|
- closes script with special opcode <---------+ |
|
||
|
|
- script is available in non-volatile memory |
|
||
|
|
via PcdS3BootScriptTablePrivateDataPtr --+ |
|
||
|
|
| |
|
||
|
|
BootScriptExecutorDxe | |
|
||
|
|
S3BootScriptLib [PiDxeS3BootScriptLib] | |
|
||
|
|
- Knows about boot script location by <----+ |
|
||
|
|
synchronizing with the other library |
|
||
|
|
instance via |
|
||
|
|
PcdS3BootScriptTablePrivateDataPtr. |
|
||
|
|
- Copies relocated image of itself to |
|
||
|
|
reserved memory. --------------------------------+ |
|
||
|
|
- Saved image contains pointer to boot script. ---|--+ |
|
||
|
|
| | |
|
||
|
|
Runtime: | | |
|
||
|
|
| | |
|
||
|
|
(c) OS is booted, writes OS waking vector to FACS, | | |
|
||
|
|
suspends machine | | |
|
||
|
|
| | |
|
||
|
|
S3 Resume (PEI): | | |
|
||
|
|
| | |
|
||
|
|
(d) PlatformPei sets S3 Boot Mode based on CMOS | | |
|
||
|
|
| | |
|
||
|
|
(e) DXE core is skipped and EFI_PEI_S3_RESUME2 is | | |
|
||
|
|
called as last step of PEI | | |
|
||
|
|
| | |
|
||
|
|
(f) S3Resume2Pei retrieves from LockBox: | | |
|
||
|
|
- ACPI S3 Context (path to FACS) <------------------|--|--+
|
||
|
|
| | |
|
||
|
|
+------------------|--|--+
|
||
|
|
- Boot Script Executor Image <----------------------+ | |
|
||
|
|
| |
|
||
|
|
(g) BootScriptExecutorDxe | |
|
||
|
|
S3BootScriptLib [PiDxeS3BootScriptLib] | |
|
||
|
|
- executes boot script <-----------------------------+ |
|
||
|
|
|
|
||
|
|
(h) OS waking vector available from ACPI S3 Context / FACS <--+
|
||
|
|
is called
|
||
|
|
|
||
|
|
A comprehensive memory map of OVMF
|
||
|
|
----------------------------------
|
||
|
|
|
||
|
|
The following section gives a detailed analysis of memory ranges below 4 GB
|
||
|
|
that OVMF statically uses.
|
||
|
|
|
||
|
|
In the rightmost column, the PCD entry is identified by which the source refers
|
||
|
|
to the address or size in question.
|
||
|
|
|
||
|
|
The flash-covered range has been discussed previously in "Firmware image
|
||
|
|
structure", therefore we include it only for completeness. Due to the fact that
|
||
|
|
this range is always backed by a memory mapped device (and never RAM), it is
|
||
|
|
unaffected by S3 (suspend to RAM and resume).
|
||
|
|
|
||
|
|
+--------------------------+ 4194304 KB
|
||
|
|
| |
|
||
|
|
| SECFV | size: 208 KB
|
||
|
|
| |
|
||
|
|
+--------------------------+ 4194096 KB
|
||
|
|
| |
|
||
|
|
| FVMAIN_COMPACT | size: 1712 KB
|
||
|
|
| |
|
||
|
|
+--------------------------+ 4192384 KB
|
||
|
|
| |
|
||
|
|
| variable store | size: 64 KB PcdFlashNvStorageFtwSpareSize
|
||
|
|
| spare area |
|
||
|
|
| |
|
||
|
|
+--------------------------+ 4192320 KB PcdOvmfFlashNvStorageFtwSpareBase
|
||
|
|
| |
|
||
|
|
| FTW working block | size: 4 KB PcdFlashNvStorageFtwWorkingSize
|
||
|
|
| |
|
||
|
|
+--------------------------+ 4192316 KB PcdOvmfFlashNvStorageFtwWorkingBase
|
||
|
|
| |
|
||
|
|
| Event log of | size: 4 KB PcdOvmfFlashNvStorageEventLogSize
|
||
|
|
| non-volatile storage |
|
||
|
|
| |
|
||
|
|
+--------------------------+ 4192312 KB PcdOvmfFlashNvStorageEventLogBase
|
||
|
|
| |
|
||
|
|
| variable store | size: 56 KB PcdFlashNvStorageVariableSize
|
||
|
|
| |
|
||
|
|
+--------------------------+ 4192256 KB PcdOvmfFlashNvStorageVariableBase
|
||
|
|
|
||
|
|
The flash-mapped image of OVMF.fd covers the entire structure above (2048 KB).
|
||
|
|
|
||
|
|
When using the split files, the address 4192384 KB
|
||
|
|
(PcdOvmfFlashNvStorageFtwSpareBase + PcdFlashNvStorageFtwSpareSize) is the
|
||
|
|
boundary between the mapped images of OVMF_VARS.fd (56 KB + 4 KB + 4 KB + 64 KB
|
||
|
|
= 128 KB) and OVMF_CODE.fd (1712 KB + 208 KB = 1920 KB).
|
||
|
|
|
||
|
|
With regard to RAM that is statically used by OVMF, S3 (suspend to RAM and
|
||
|
|
resume) complicates matters. Many ranges have been introduced only to support
|
||
|
|
S3, hence for all ranges below, the following questions will be audited:
|
||
|
|
|
||
|
|
(a) when and how a given range is initialized after first boot of the VM,
|
||
|
|
(b) how it is protected from memory allocations during DXE,
|
||
|
|
(c) how it is protected from the OS,
|
||
|
|
(d) how it is accessed on the S3 resume path,
|
||
|
|
(e) how it is accessed on the warm reset path.
|
||
|
|
|
||
|
|
Importantly, the term "protected" is meant as protection against inadvertent
|
||
|
|
reallocations and overwrites by co-operating DXE and OS modules. It does not
|
||
|
|
imply security against malicious code.
|
||
|
|
|
||
|
|
+--------------------------+ 17408 KB
|
||
|
|
| |
|
||
|
|
|DXEFV from FVMAIN_COMPACT | size: 8192 KB PcdOvmfDxeMemFvSize
|
||
|
|
| decompressed firmware |
|
||
|
|
| volume with DXE modules |
|
||
|
|
| |
|
||
|
|
+--------------------------+ 9216 KB PcdOvmfDxeMemFvBase
|
||
|
|
| |
|
||
|
|
|PEIFV from FVMAIN_COMPACT | size: 896 KB PcdOvmfPeiMemFvSize
|
||
|
|
| decompressed firmware |
|
||
|
|
| volume with PEI modules |
|
||
|
|
| |
|
||
|
|
+--------------------------+ 8320 KB PcdOvmfPeiMemFvBase
|
||
|
|
| |
|
||
|
|
| permanent PEI memory for | size: 32 KB PcdS3AcpiReservedMemorySize
|
||
|
|
| the S3 resume path |
|
||
|
|
| |
|
||
|
|
+--------------------------+ 8288 KB PcdS3AcpiReservedMemoryBase
|
||
|
|
| |
|
||
|
|
| temporary SEC/PEI heap | size: 32 KB PcdOvmfSecPeiTempRamSize
|
||
|
|
| and stack |
|
||
|
|
| |
|
||
|
|
+--------------------------+ 8256 KB PcdOvmfSecPeiTempRamBase
|
||
|
|
| |
|
||
|
|
| unused | size: 32 KB
|
||
|
|
| |
|
||
|
|
+--------------------------+ 8224 KB
|
||
|
|
| |
|
||
|
|
| SEC's table of | size: 4 KB PcdGuidedExtractHandlerTableSize
|
||
|
|
| GUIDed section handlers |
|
||
|
|
| |
|
||
|
|
+--------------------------+ 8220 KB PcdGuidedExtractHandlerTableAddress
|
||
|
|
| |
|
||
|
|
| LockBox storage | size: 4 KB PcdOvmfLockBoxStorageSize
|
||
|
|
| |
|
||
|
|
+--------------------------+ 8216 KB PcdOvmfLockBoxStorageBase
|
||
|
|
| |
|
||
|
|
| early page tables on X64 | size: 24 KB PcdOvmfSecPageTablesSize
|
||
|
|
| |
|
||
|
|
+--------------------------+ 8192 KB PcdOvmfSecPageTablesBase
|
||
|
|
|
||
|
|
(1) Early page tables on X64:
|
||
|
|
|
||
|
|
(a) when and how it is initialized after first boot of the VM
|
||
|
|
|
||
|
|
The range is filled in during the SEC phase
|
||
|
|
[OvmfPkg/ResetVector/Ia32/PageTables64.asm]. The CR3 register is verified
|
||
|
|
against the base address in SecCoreStartupWithStack()
|
||
|
|
[OvmfPkg/Sec/SecMain.c].
|
||
|
|
|
||
|
|
(b) how it is protected from memory allocations during DXE
|
||
|
|
|
||
|
|
If S3 was enabled on the QEMU command line (see "-global
|
||
|
|
PIIX4_PM.disable_s3=0" earlier), then InitializeRamRegions()
|
||
|
|
[OvmfPkg/PlatformPei/MemDetect.c] protects the range with an AcpiNVS memory
|
||
|
|
allocation HOB, in PEI.
|
||
|
|
|
||
|
|
If S3 was disabled, then this range is not protected. DXE's own page tables
|
||
|
|
are first built while still in PEI (see HandOffToDxeCore()
|
||
|
|
[MdeModulePkg/Core/DxeIplPeim/X64/DxeLoadFunc.c]). Those tables are located
|
||
|
|
in permanent PEI memory. After CR3 is switched over to them (which occurs
|
||
|
|
before jumping to the DXE core entry point), we don't have to preserve the
|
||
|
|
initial tables.
|
||
|
|
|
||
|
|
(c) how it is protected from the OS
|
||
|
|
|
||
|
|
If S3 is enabled, then (1b) reserves it from the OS too.
|
||
|
|
|
||
|
|
If S3 is disabled, then the range needs no protection.
|
||
|
|
|
||
|
|
(d) how it is accessed on the S3 resume path
|
||
|
|
|
||
|
|
It is rewritten same as in (1a), which is fine because (1c) reserved it.
|
||
|
|
|
||
|
|
(e) how it is accessed on the warm reset path
|
||
|
|
|
||
|
|
It is rewritten same as in (1a).
|
||
|
|
|
||
|
|
(2) LockBox storage:
|
||
|
|
|
||
|
|
(a) when and how it is initialized after first boot of the VM
|
||
|
|
|
||
|
|
InitializeRamRegions() [OvmfPkg/PlatformPei/MemDetect.c] zeroes out the
|
||
|
|
area during PEI. This is correct but not strictly necessary, since on first
|
||
|
|
boot the area is zero-filled anyway.
|
||
|
|
|
||
|
|
The LockBox signature of the area is filled in by the PEI module or DXE
|
||
|
|
driver that has been linked against OVMF's LockBoxLib and is run first. The
|
||
|
|
signature is written in LockBoxLibInitialize()
|
||
|
|
[OvmfPkg/Library/LockBoxLib/LockBoxLib.c].
|
||
|
|
|
||
|
|
Any module calling SaveLockBox() [OvmfPkg/Library/LockBoxLib/LockBoxLib.c]
|
||
|
|
will co-populate this area.
|
||
|
|
|
||
|
|
(b) how it is protected from memory allocations during DXE
|
||
|
|
|
||
|
|
If S3 is enabled, then InitializeRamRegions()
|
||
|
|
[OvmfPkg/PlatformPei/MemDetect.c] protects the range as AcpiNVS.
|
||
|
|
|
||
|
|
Otherwise, the range is covered with a BootServicesData memory allocation
|
||
|
|
HOB.
|
||
|
|
|
||
|
|
(c) how it is protected from the OS
|
||
|
|
|
||
|
|
If S3 is enabled, then (2b) protects it sufficiently.
|
||
|
|
|
||
|
|
Otherwise the range requires no runtime protection, and the
|
||
|
|
BootServicesData allocation type from (2b) ensures that the range will be
|
||
|
|
released to the OS.
|
||
|
|
|
||
|
|
(d) how it is accessed on the S3 resume path
|
||
|
|
|
||
|
|
The S3 Resume PEIM restores data from the LockBox, which has been correctly
|
||
|
|
protected in (2c).
|
||
|
|
|
||
|
|
(e) how it is accessed on the warm reset path
|
||
|
|
|
||
|
|
InitializeRamRegions() [OvmfPkg/PlatformPei/MemDetect.c] zeroes out the
|
||
|
|
range during PEI, effectively emptying the LockBox. Modules will
|
||
|
|
re-populate the LockBox as described in (2a).
|
||
|
|
|
||
|
|
(3) SEC's table of GUIDed section handlers
|
||
|
|
|
||
|
|
(a) when and how it is initialized after first boot of the VM
|
||
|
|
|
||
|
|
The following two library instances are linked into SecMain:
|
||
|
|
- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib,
|
||
|
|
- MdePkg/Library/BaseExtractGuidedSectionLib.
|
||
|
|
|
||
|
|
The first library registers its LZMA decompressor plugin (which is a called
|
||
|
|
a "section handler") by calling the second library:
|
||
|
|
|
||
|
|
LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
|
||
|
|
ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
|
||
|
|
|
||
|
|
The second library maintains its table of registered "section handlers", to
|
||
|
|
be indexed by GUID, in this fixed memory area, independently of S3
|
||
|
|
enablement.
|
||
|
|
|
||
|
|
(The decompression of FVMAIN_COMPACT's FFS file section that contains the
|
||
|
|
PEIFV and DXEFV firmware volumes occurs with the LZMA decompressor
|
||
|
|
registered above. See (6) and (7) below.)
|
||
|
|
|
||
|
|
(b) how it is protected from memory allocations during DXE
|
||
|
|
|
||
|
|
There is no need to protect this area from DXE: because nothing else in
|
||
|
|
OVMF links against BaseExtractGuidedSectionLib, the area loses its
|
||
|
|
significance as soon as OVMF progresses from SEC to PEI, therefore DXE is
|
||
|
|
allowed to overwrite the region.
|
||
|
|
|
||
|
|
(c) how it is protected from the OS
|
||
|
|
|
||
|
|
When S3 is enabled, we cover the range with an AcpiNVS memory allocation
|
||
|
|
HOB in InitializeRamRegions().
|
||
|
|
|
||
|
|
When S3 is disabled, the range is not protected.
|
||
|
|
|
||
|
|
(d) how it is accessed on the S3 resume path
|
||
|
|
|
||
|
|
The table of registered section handlers is again managed by
|
||
|
|
BaseExtractGuidedSectionLib linked into SecMain exclusively. Section
|
||
|
|
handler registrations update the table in-place (based on GUID matches).
|
||
|
|
|
||
|
|
(e) how it is accessed on the warm reset path
|
||
|
|
|
||
|
|
If S3 is enabled, then the OS won't damage the table (due to (3c)), thus
|
||
|
|
see (3d).
|
||
|
|
|
||
|
|
If S3 is disabled, then the OS has most probably overwritten the range with
|
||
|
|
its own data, hence (3a) -- complete reinitialization -- will come into
|
||
|
|
effect, based on the table signature check in BaseExtractGuidedSectionLib.
|
||
|
|
|
||
|
|
(4) temporary SEC/PEI heap and stack
|
||
|
|
|
||
|
|
(a) when and how it is initialized after first boot of the VM
|
||
|
|
|
||
|
|
The range is configured in [OvmfPkg/Sec/X64/SecEntry.S] and
|
||
|
|
SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]. The stack half is read &
|
||
|
|
written by the CPU transparently. The heap half is used for memory
|
||
|
|
allocations during PEI.
|
||
|
|
|
||
|
|
Data is migrated out (to permanent PEI stack & memory) in (or soon after)
|
||
|
|
PublishPeiMemory() [OvmfPkg/PlatformPei/MemDetect.c].
|
||
|
|
|
||
|
|
(b) how it is protected from memory allocations during DXE
|
||
|
|
|
||
|
|
It is not necessary to protect this range during DXE because its use ends
|
||
|
|
still in PEI.
|
||
|
|
|
||
|
|
(c) how it is protected from the OS
|
||
|
|
|
||
|
|
If S3 is enabled, then InitializeRamRegions()
|
||
|
|
[OvmfPkg/PlatformPei/MemDetect.c] reserves it as AcpiNVS.
|
||
|
|
|
||
|
|
If S3 is disabled, then the range doesn't require protection.
|
||
|
|
|
||
|
|
(d) how it is accessed on the S3 resume path
|
||
|
|
|
||
|
|
Same as in (4a), except the target area of the migration triggered by
|
||
|
|
PublishPeiMemory() [OvmfPkg/PlatformPei/MemDetect.c] is different -- see
|
||
|
|
(5).
|
||
|
|
|
||
|
|
(e) how it is accessed on the warm reset path
|
||
|
|
|
||
|
|
Same as in (4a). The stack and heap halves both may contain garbage, but it
|
||
|
|
doesn't matter.
|
||
|
|
|
||
|
|
(5) permanent PEI memory for the S3 resume path
|
||
|
|
|
||
|
|
(a) when and how it is initialized after first boot of the VM
|
||
|
|
|
||
|
|
No particular initialization or use.
|
||
|
|
|
||
|
|
(b) how it is protected from memory allocations during DXE
|
||
|
|
|
||
|
|
We don't need to protect this area during DXE.
|
||
|
|
|
||
|
|
(c) how it is protected from the OS
|
||
|
|
|
||
|
|
When S3 is enabled, InitializeRamRegions()
|
||
|
|
[OvmfPkg/PlatformPei/MemDetect.c] makes sure the OS stays away by covering
|
||
|
|
the range with an AcpiNVS memory allocation HOB.
|
||
|
|
|
||
|
|
When S3 is disabled, the range needs no protection.
|
||
|
|
|
||
|
|
(d) how it is accessed on the S3 resume path
|
||
|
|
|
||
|
|
PublishPeiMemory() installs the range as permanent RAM for PEI. The range
|
||
|
|
will serve as stack and will satisfy allocation requests during the rest of
|
||
|
|
PEI. OS data won't overlap due to (5c).
|
||
|
|
|
||
|
|
(e) how it is accessed on the warm reset path
|
||
|
|
|
||
|
|
Same as (5a).
|
||
|
|
|
||
|
|
(6) PEIFV -- decompressed firmware volume with PEI modules
|
||
|
|
|
||
|
|
(a) when and how it is initialized after first boot of the VM
|
||
|
|
|
||
|
|
DecompressMemFvs() [OvmfPkg/Sec/SecMain.c] populates the area, by
|
||
|
|
decompressing the flash-mapped FVMAIN_COMPACT volume's contents. (Refer to
|
||
|
|
"Firmware image structure".)
|
||
|
|
|
||
|
|
(b) how it is protected from memory allocations during DXE
|
||
|
|
|
||
|
|
When S3 is disabled, PeiFvInitialization() [OvmfPkg/PlatformPei/Fv.c]
|
||
|
|
covers the range with a BootServicesData memory allocation HOB.
|
||
|
|
|
||
|
|
When S3 is enabled, the same is coverage is ensured, just with the stronger
|
||
|
|
AcpiNVS memory allocation type.
|
||
|
|
|
||
|
|
(c) how it is protected from the OS
|
||
|
|
|
||
|
|
When S3 is disabled, it is not necessary to keep the range from the OS.
|
||
|
|
|
||
|
|
Otherwise the AcpiNVS type allocation from (6b) provides coverage.
|
||
|
|
|
||
|
|
(d) how it is accessed on the S3 resume path
|
||
|
|
|
||
|
|
Rather than decompressing it again from FVMAIN_COMPACT, GetS3ResumePeiFv()
|
||
|
|
[OvmfPkg/Sec/SecMain.c] reuses the protected area for parsing / execution
|
||
|
|
from (6c).
|
||
|
|
|
||
|
|
(e) how it is accessed on the warm reset path
|
||
|
|
|
||
|
|
Same as (6a).
|
||
|
|
|
||
|
|
(7) DXEFV -- decompressed firmware volume with DXE modules
|
||
|
|
|
||
|
|
(a) when and how it is initialized after first boot of the VM
|
||
|
|
|
||
|
|
Same as (6a).
|
||
|
|
|
||
|
|
(b) how it is protected from memory allocations during DXE
|
||
|
|
|
||
|
|
PeiFvInitialization() [OvmfPkg/PlatformPei/Fv.c] covers the range with a
|
||
|
|
BootServicesData memory allocation HOB.
|
||
|
|
|
||
|
|
(c) how it is protected from the OS
|
||
|
|
|
||
|
|
The OS is allowed to release and reuse this range.
|
||
|
|
|
||
|
|
(d) how it is accessed on the S3 resume path
|
||
|
|
|
||
|
|
It's not; DXE never runs during S3 resume.
|
||
|
|
|
||
|
|
(e) how it is accessed on the warm reset path
|
||
|
|
|
||
|
|
Same as in (7a).
|
||
|
|
|
||
|
|
Known Secure Boot limitations
|
||
|
|
-----------------------------
|
||
|
|
|
||
|
|
Under "Motivation" we've mentioned that OVMF's Secure Boot implementation is
|
||
|
|
not suitable for production use yet -- it's only good for development and
|
||
|
|
testing of standards-conformant, non-malicious guest code (UEFI and operating
|
||
|
|
system alike).
|
||
|
|
|
||
|
|
Now that we've examined the persistent flash device, the workings of S3, and
|
||
|
|
the memory map, we can discuss two currently known shortcomings of OVMF's
|
||
|
|
Secure Boot that in fact make it insecure. (Clearly problems other than these
|
||
|
|
two might exist; the set of issues considered here is not meant to be
|
||
|
|
exhaustive.)
|
||
|
|
|
||
|
|
One trait of Secure Boot is tamper-evidence. Secure Boot may not prevent
|
||
|
|
malicious modification of software components (for example, operating system
|
||
|
|
drivers), but by being the root of integrity on a platform, it can catch (or
|
||
|
|
indirectly contribute to catching) unauthorized changes, by way of signature
|
||
|
|
and certificate checks at the earliest phases of boot.
|
||
|
|
|
||
|
|
If an attacker can tamper with key material stored in authenticated and/or
|
||
|
|
boot-time only persistent variables (for example, PK, KEK, db, dbt, dbx), then
|
||
|
|
the intended security of this scheme is compromised. The UEFI 2.4A
|
||
|
|
specification says
|
||
|
|
|
||
|
|
- in section 28.3.4:
|
||
|
|
|
||
|
|
Platform Keys:
|
||
|
|
|
||
|
|
The public key must be stored in non-volatile storage which is tamper and
|
||
|
|
delete resistant.
|
||
|
|
|
||
|
|
Key Exchange Keys:
|
||
|
|
|
||
|
|
The public key must be stored in non-volatile storage which is tamper
|
||
|
|
resistant.
|
||
|
|
|
||
|
|
- in section 28.6.1:
|
||
|
|
|
||
|
|
The signature database variables db, dbt, and dbx must be stored in
|
||
|
|
tamper-resistant non-volatile storage.
|
||
|
|
|
||
|
|
(1) The combination of QEMU, KVM, and OVMF does not provide this kind of
|
||
|
|
resistance. The variable store in the emulated flash chip is directly
|
||
|
|
accessible to, and reprogrammable by, UEFI drivers, applications, and
|
||
|
|
operating systems.
|
||
|
|
|
||
|
|
(2) Under "S3 (suspend to RAM and resume)" we pointed out that the LockBox
|
||
|
|
storage must be similarly secure and tamper-resistant.
|
||
|
|
|
||
|
|
On the S3 resume path, the PEIM providing EFI_PEI_S3_RESUME2_PPI
|
||
|
|
(UefiCpuPkg/Universal/Acpi/S3Resume2Pei) restores and interprets data from
|
||
|
|
the LockBox that has been saved there during boot. This PEIM, being part of
|
||
|
|
the firmware, has full access to the platform. If an operating system can
|
||
|
|
tamper with the contents of the LockBox, then at the next resume the
|
||
|
|
platform's integrity might be subverted.
|
||
|
|
|
||
|
|
OVMF stores the LockBox in normal guest RAM (refer to the memory map
|
||
|
|
section above). Operating systems and third party UEFI drivers and UEFI
|
||
|
|
applications that respect the UEFI memory map will not inadvertently
|
||
|
|
overwrite the LockBox storage, but there's nothing to prevent eg. a
|
||
|
|
malicious kernel from modifying the LockBox.
|
||
|
|
|
||
|
|
One means to address these issues is SMM and SMRAM (System Management Mode and
|
||
|
|
System Management RAM).
|
||
|
|
|
||
|
|
During boot and resume, the firmware can enter and leave SMM and access SMRAM.
|
||
|
|
Before the DXE phase is left, and control is transferred to the BDS phase (when
|
||
|
|
third party UEFI drivers and applications can be loaded, and an operating
|
||
|
|
system can be loaded), SMRAM is locked in hardware, and subsequent modules
|
||
|
|
cannot access it directly. (See EFI_DXE_SMM_READY_TO_LOCK_PROTOCOL.)
|
||
|
|
|
||
|
|
Once SMRAM has been locked, UEFI drivers and the operating system can enter SMM
|
||
|
|
by raising a System Management Interrupt (SMI), at which point trusted code
|
||
|
|
(part of the platform firmware) takes control. SMRAM is also unlocked by
|
||
|
|
platform reset, at which point the boot firmware takes control again.
|
||
|
|
|
||
|
|
Variable store and LockBox in SMRAM
|
||
|
|
-----------------------------------
|
||
|
|
|
||
|
|
Edk2 provides almost all components to implement the variable store and the
|
||
|
|
LockBox in SMRAM. In this section we summarize ideas for utilizing those
|
||
|
|
facilities.
|
||
|
|
|
||
|
|
The SMRAM and SMM infrastructure in edk2 is built up as follows:
|
||
|
|
|
||
|
|
(1) The platform hardware provides SMM / SMI / SMRAM.
|
||
|
|
|
||
|
|
Qemu/KVM doesn't support these features currently and should implement them
|
||
|
|
in the longer term.
|
||
|
|
|
||
|
|
(2) The platform vendor (in this case, OVMF developers) implement device
|
||
|
|
drivers for the platform's System Management Mode:
|
||
|
|
|
||
|
|
- EFI_SMM_CONTROL2_PROTOCOL: for raising a synchronous (and/or) periodic
|
||
|
|
SMI(s); that is, for entering SMM.
|
||
|
|
|
||
|
|
- EFI_SMM_ACCESS2_PROTOCOL: for describing and accessing SMRAM.
|
||
|
|
|
||
|
|
These protocols are documented in the PI Specification, Volume 4.
|
||
|
|
|
||
|
|
(3) The platform DSC file is to include the following platform-independent
|
||
|
|
modules:
|
||
|
|
|
||
|
|
- MdeModulePkg/Core/PiSmmCore/PiSmmIpl.inf: SMM Initial Program Load
|
||
|
|
- MdeModulePkg/Core/PiSmmCore/PiSmmCore.inf: SMM Core
|
||
|
|
|
||
|
|
(4) At this point, modules of type DXE_SMM_DRIVER can be loaded.
|
||
|
|
|
||
|
|
Such drivers are privileged. They run in SMM, have access to SMRAM, and are
|
||
|
|
separated and switched from other drivers through SMIs. Secure
|
||
|
|
communication between unprivileged (non-SMM) and privileged (SMM) drivers
|
||
|
|
happens through EFI_SMM_COMMUNICATION_PROTOCOL (implemented by the SMM
|
||
|
|
Core, see (3)).
|
||
|
|
|
||
|
|
DXE_SMM_DRIVER modules must sanitize their input (coming from unprivileged
|
||
|
|
drivers) carefully.
|
||
|
|
|
||
|
|
(5) The authenticated runtime variable services driver (for Secure Boot builds)
|
||
|
|
is located under "SecurityPkg/VariableAuthenticated/RuntimeDxe". OVMF
|
||
|
|
currently builds the driver (a DXE_RUNTIME_DRIVER module) with the
|
||
|
|
"VariableRuntimeDxe.inf" control file (refer to "OvmfPkg/OvmfPkgX64.dsc"),
|
||
|
|
which does not use SMM.
|
||
|
|
|
||
|
|
The directory includes two more INF files:
|
||
|
|
|
||
|
|
- VariableSmm.inf -- module type: DXE_SMM_DRIVER. A privileged driver that
|
||
|
|
runs in SMM and has access to SMRAM.
|
||
|
|
|
||
|
|
- VariableSmmRuntimeDxe.inf -- module type: DXE_RUNTIME_DRIVER. A
|
||
|
|
non-privileged driver that implements the variable runtime services
|
||
|
|
(replacing the current "VariableRuntimeDxe.inf" file) by communicating
|
||
|
|
with the above privileged SMM half via EFI_SMM_COMMUNICATION_PROTOCOL.
|
||
|
|
|
||
|
|
(6) An SMRAM-based LockBox implementation needs to be discussed in two parts,
|
||
|
|
because the LockBox is accessed in both PEI and DXE.
|
||
|
|
|
||
|
|
(a) During DXE, drivers save data in the LockBox. A save operation is
|
||
|
|
layered as follows:
|
||
|
|
|
||
|
|
- The unprivileged driver wishing to store data in the LockBox links
|
||
|
|
against the "MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxDxeLib.inf"
|
||
|
|
library instance.
|
||
|
|
|
||
|
|
The library allows the unprivileged driver to format requests for the
|
||
|
|
privileged SMM LockBox driver (see below), and to parse responses.
|
||
|
|
|
||
|
|
- The privileged SMM LockBox driver is built from
|
||
|
|
"MdeModulePkg/Universal/LockBox/SmmLockBox/SmmLockBox.inf". This
|
||
|
|
driver has module type DXE_SMM_DRIVER and can access SMRAM.
|
||
|
|
|
||
|
|
The driver delegates command parsing and response formatting to
|
||
|
|
"MdeModulePkg/Library/SmmLockBoxLib/SmmLockBoxSmmLib.inf".
|
||
|
|
|
||
|
|
- The above two halves (unprivileged and privileged) mirror what we've
|
||
|
|
seen in case of the variable service drivers, under (5).
|
||
|
|
|
||
|
|
(b) In PEI, the S3 Resume PEIM (UefiCpuPkg/Universal/Acpi/S3Resume2Pei)
|
||
|
|
retrieves data from the LockBox.
|
||
|
|
|
||
|
|
Presumably, S3Resume2Pei should be considered an "unprivileged PEIM",
|
||
|
|
and the SMRAM access should be layered as seen in DXE. Unfortunately,
|
||
|
|
edk2 does not implement all of the layers in PEI -- the code either
|
||
|
|
doesn't exist, or it is not open source:
|
||
|
|
|
||
|
|
role | DXE: protocol/module | PEI: PPI/module
|
||
|
|
-------------+--------------------------------+------------------------------
|
||
|
|
unprivileged | any | S3Resume2Pei.inf
|
||
|
|
driver | |
|
||
|
|
-------------+--------------------------------+------------------------------
|
||
|
|
command | LIBRARY_CLASS = LockBoxLib | LIBRARY_CLASS = LockBoxLib
|
||
|
|
formatting | |
|
||
|
|
and response | SmmLockBoxDxeLib.inf | SmmLockBoxPeiLib.inf
|
||
|
|
parsing | |
|
||
|
|
-------------+--------------------------------+------------------------------
|
||
|
|
privilege | EFI_SMM_COMMUNICATION_PROTOCOL | EFI_PEI_SMM_COMMUNICATION_PPI
|
||
|
|
separation | |
|
||
|
|
| PiSmmCore.inf | missing!
|
||
|
|
-------------+--------------------------------+------------------------------
|
||
|
|
platform SMM | EFI_SMM_CONTROL2_PROTOCOL | PEI_SMM_CONTROL_PPI
|
||
|
|
and SMRAM | EFI_SMM_ACCESS2_PROTOCOL | PEI_SMM_ACCESS_PPI
|
||
|
|
access | |
|
||
|
|
| to be done in OVMF | to be done in OVMF
|
||
|
|
-------------+--------------------------------+------------------------------
|
||
|
|
command | LIBRARY_CLASS = LockBoxLib | LIBRARY_CLASS = LockBoxLib
|
||
|
|
parsing and | |
|
||
|
|
response | SmmLockBoxSmmLib.inf | missing!
|
||
|
|
formatting | |
|
||
|
|
-------------+--------------------------------+------------------------------
|
||
|
|
privileged | SmmLockBox.inf | missing!
|
||
|
|
LockBox | |
|
||
|
|
driver | |
|
||
|
|
|
||
|
|
Alternatively, in the future OVMF might be able to provide a LockBoxLib
|
||
|
|
instance (an SmmLockBoxPeiLib substitute) for S3Resume2Pei that
|
||
|
|
accesses SMRAM directly, eliminating the need for deeper layers in the
|
||
|
|
stack (that is, EFI_PEI_SMM_COMMUNICATION_PPI and deeper).
|
||
|
|
|
||
|
|
In fact, a "thin" EFI_PEI_SMM_COMMUNICATION_PPI implementation whose
|
||
|
|
sole Communicate() member invariably returns EFI_NOT_STARTED would
|
||
|
|
cause the current SmmLockBoxPeiLib library instance to directly perform
|
||
|
|
full-depth SMRAM access and LockBox search, obviating the "missing"
|
||
|
|
cells. (With reference to A Tour Beyond BIOS: Implementing S3 Resume
|
||
|
|
with EDK2, by Jiewen Yao and Vincent Zimmer, October 2014.)
|
||
|
|
|
||
|
|
Select features
|
||
|
|
---------------
|
||
|
|
|
||
|
|
In this section we'll browse the top-level "OvmfPkg" package directory, and
|
||
|
|
discuss the more interesting drivers and libraries that have not been mentioned
|
||
|
|
thus far.
|
||
|
|
|
||
|
|
X64-specific reset vector for OVMF
|
||
|
|
..................................
|
||
|
|
|
||
|
|
The "OvmfPkg/ResetVector" directory customizes the reset vector (found in
|
||
|
|
"UefiCpuPkg/ResetVector/Vtf0") for "OvmfPkgX64.fdf", that is, when the SEC/PEI
|
||
|
|
phases run in 64-bit (ie. long) mode.
|
||
|
|
|
||
|
|
The reset vector's control flow looks roughly like:
|
||
|
|
|
||
|
|
resetVector [Ia16/ResetVectorVtf0.asm]
|
||
|
|
EarlyBspInitReal16 [Ia16/Init16.asm]
|
||
|
|
Main16 [Main.asm]
|
||
|
|
EarlyInit16 [Ia16/Init16.asm]
|
||
|
|
|
||
|
|
; Transition the processor from
|
||
|
|
; 16-bit real mode to 32-bit flat mode
|
||
|
|
TransitionFromReal16To32BitFlat [Ia16/Real16ToFlat32.asm]
|
||
|
|
|
||
|
|
; Search for the
|
||
|
|
; Boot Firmware Volume (BFV)
|
||
|
|
Flat32SearchForBfvBase [Ia32/SearchForBfvBase.asm]
|
||
|
|
|
||
|
|
; Search for the SEC entry point
|
||
|
|
Flat32SearchForSecEntryPoint [Ia32/SearchForSecEntry.asm]
|
||
|
|
|
||
|
|
%ifdef ARCH_IA32
|
||
|
|
; Jump to the 32-bit SEC entry point
|
||
|
|
%else
|
||
|
|
; Transition the processor
|
||
|
|
; from 32-bit flat mode
|
||
|
|
; to 64-bit flat mode
|
||
|
|
Transition32FlatTo64Flat [Ia32/Flat32ToFlat64.asm]
|
||
|
|
|
||
|
|
SetCr3ForPageTables64 [Ia32/PageTables64.asm]
|
||
|
|
; set CR3 to page tables
|
||
|
|
; built into the ROM image
|
||
|
|
|
||
|
|
; enable PAE
|
||
|
|
; set LME
|
||
|
|
; enable paging
|
||
|
|
|
||
|
|
; Jump to the 64-bit SEC entry point
|
||
|
|
%endif
|
||
|
|
|
||
|
|
On physical platforms, the initial page tables referenced by
|
||
|
|
SetCr3ForPageTables64 are built statically into the flash device image, and are
|
||
|
|
present in ROM at runtime. This is fine on physical platforms because the
|
||
|
|
pre-built page table entries have the Accessed and Dirty bits set from the
|
||
|
|
start.
|
||
|
|
|
||
|
|
Accordingly, for OVMF running in long mode on qemu/KVM, the initial page tables
|
||
|
|
were mapped as a KVM_MEM_READONLY slot, as part of QEMU's pflash device (refer
|
||
|
|
to "Firmware image structure" above).
|
||
|
|
|
||
|
|
In spite of the Accessed and Dirty bits being pre-set in the read-only,
|
||
|
|
in-flash PTEs, in a virtual machine attempts are made to update said PTE bits,
|
||
|
|
differently from physical hardware. The component attempting to update the
|
||
|
|
read-only PTEs can be one of the following:
|
||
|
|
|
||
|
|
- The processor itself, if it supports nested paging, and the user enables that
|
||
|
|
processor feature,
|
||
|
|
|
||
|
|
- KVM code implementing shadow paging, otherwise.
|
||
|
|
|
||
|
|
The first case presents no user-visible symptoms, but the second case (KVM,
|
||
|
|
shadow paging) used to cause a triple fault, prior to Linux commit ba6a354
|
||
|
|
("KVM: mmu: allow page tables to be in read-only slots").
|
||
|
|
|
||
|
|
For compatibility with earlier KVM versions, the OvmfPkg/ResetVector directory
|
||
|
|
adapts the generic reset vector code as follows:
|
||
|
|
|
||
|
|
Transition32FlatTo64Flat [UefiCpuPkg/.../Ia32/Flat32ToFlat64.asm]
|
||
|
|
|
||
|
|
SetCr3ForPageTables64 [OvmfPkg/ResetVector/Ia32/PageTables64.asm]
|
||
|
|
|
||
|
|
; dynamically build the initial page tables in RAM, at address
|
||
|
|
; PcdOvmfSecPageTablesBase (refer to the memory map above),
|
||
|
|
; identity-mapping the first 4 GB of address space
|
||
|
|
|
||
|
|
; set CR3 to PcdOvmfSecPageTablesBase
|
||
|
|
|
||
|
|
; enable PAE
|
||
|
|
; set LME
|
||
|
|
; enable paging
|
||
|
|
|
||
|
|
This way the PTEs that earlier KVM versions try to update (during shadow
|
||
|
|
paging) are located in a read-write memory slot, and the write attempts
|
||
|
|
succeed.
|
||
|
|
|
||
|
|
Client library for QEMU's firmware configuration interface
|
||
|
|
..........................................................
|
||
|
|
|
||
|
|
QEMU provides a write-only, 16-bit wide control port, and a read-write, 8-bit
|
||
|
|
wide data port for exchanging configuration elements with the firmware.
|
||
|
|
|
||
|
|
The firmware writes a selector (a key) to the control port (0x510), and then
|
||
|
|
reads the corresponding configuration data (produced by QEMU) from the data
|
||
|
|
port (0x511).
|
||
|
|
|
||
|
|
If the selected entry is writable, the firmware may overwrite it. If QEMU has
|
||
|
|
associated a callback with the entry, then when the entry is completely
|
||
|
|
rewritten, QEMU runs the callback. (OVMF does not rewrite any entries at the
|
||
|
|
moment.)
|
||
|
|
|
||
|
|
A number of selector values (keys) are predefined. In particular, key 0x19
|
||
|
|
selects (returns) a directory of { name, selector, size } triplets, roughly
|
||
|
|
speaking.
|
||
|
|
|
||
|
|
The firmware can request configuration elements by well-known name as well, by
|
||
|
|
looking up the selector value first in the directory, by name, and then writing
|
||
|
|
the selector to the control port. The number of bytes to read subsequently from
|
||
|
|
the data port is known from the directory entry's "size" field.
|
||
|
|
|
||
|
|
By convention, directory entries (well-known symbolic names of configuration
|
||
|
|
elements) are formatted as POSIX pathnames. For example, the array selected by
|
||
|
|
the "etc/system-states" name indicates (among other things) whether the user
|
||
|
|
enabled S3 support in QEMU.
|
||
|
|
|
||
|
|
The above interface is called "fw_cfg".
|
||
|
|
|
||
|
|
The binary data associated with a symbolic name is called an "fw_cfg file".
|
||
|
|
|
||
|
|
OVMF's fw_cfg client library is found in "OvmfPkg/Library/QemuFwCfgLib". OVMF
|
||
|
|
discovers many aspects of the virtual system with it; we refer to a few
|
||
|
|
examples below.
|
||
|
|
|
||
|
|
Guest ACPI tables
|
||
|
|
.................
|
||
|
|
|
||
|
|
An operating system discovers a good amount of its hardware by parsing ACPI
|
||
|
|
tables, and by interpreting ACPI objects and methods. On physical hardware, the
|
||
|
|
platform vendor's firmware installs ACPI tables in memory that match both the
|
||
|
|
hardware present in the system and the user's firmware configuration ("BIOS
|
||
|
|
setup").
|
||
|
|
|
||
|
|
Under qemu/KVM, the owner of the (virtual) hardware configuration is QEMU.
|
||
|
|
Hardware can easily be reconfigured on the command line. Furthermore, features
|
||
|
|
like CPU hotplug, PCI hotplug, memory hotplug are continuously developed for
|
||
|
|
QEMU, and operating systems need direct ACPI support to exploit these features.
|
||
|
|
|
||
|
|
For this reason, QEMU builds its own ACPI tables dynamically, in a
|
||
|
|
self-descriptive manner, and exports them to the firmware through a complex,
|
||
|
|
multi-file fw_cfg interface. It is rooted in the "etc/table-loader" fw_cfg
|
||
|
|
file. (Further details of this interface are out of scope for this report.)
|
||
|
|
|
||
|
|
OVMF's AcpiPlatformDxe driver fetches the ACPI tables, and installs them for
|
||
|
|
the guest OS with the EFI_ACPI_TABLE_PROTOCOL (which is in turn provided by the
|
||
|
|
generic "MdeModulePkg/Universal/Acpi/AcpiTableDxe" driver).
|
||
|
|
|
||
|
|
For earlier QEMU versions and machine types (which we generally don't recommend
|
||
|
|
for OVMF; see "Scope"), the "OvmfPkg/AcpiTables" directory contains a few
|
||
|
|
static ACPI table templates. When the "etc/table-loader" fw_cfg file is
|
||
|
|
unavailable, AcpiPlatformDxe installs these default tables (with a little bit
|
||
|
|
of dynamic patching).
|
||
|
|
|
||
|
|
When OVMF runs in a Xen domU, AcpiTableDxe also installs ACPI tables that
|
||
|
|
originate from the hypervisor's environment.
|
||
|
|
|
||
|
|
Guest SMBIOS tables
|
||
|
|
...................
|
||
|
|
|
||
|
|
Quoting the SMBIOS Reference Specification,
|
||
|
|
|
||
|
|
[...] the System Management BIOS Reference Specification addresses how
|
||
|
|
motherboard and system vendors present management information about their
|
||
|
|
products in a standard format [...]
|
||
|
|
|
||
|
|
In practice SMBIOS tables are just another set of tables that the platform
|
||
|
|
vendor's firmware installs in RAM for the operating system, and, importantly,
|
||
|
|
for management applications running on the OS. Without rehashing the "Guest
|
||
|
|
ACPI tables" section in full, let's map the OVMF roles seen there from ACPI to
|
||
|
|
SMBIOS:
|
||
|
|
|
||
|
|
role | ACPI | SMBIOS
|
||
|
|
-------------------------+-------------------------+-------------------------
|
||
|
|
fw_cfg file | etc/table-loader | etc/smbios/smbios-tables
|
||
|
|
-------------------------+-------------------------+-------------------------
|
||
|
|
OVMF driver | AcpiPlatformDxe | SmbiosPlatformDxe
|
||
|
|
under "OvmfPkg" | |
|
||
|
|
-------------------------+-------------------------+-------------------------
|
||
|
|
Underlying protocol, | EFI_ACPI_TABLE_PROTOCOL | EFI_SMBIOS_PROTOCOL
|
||
|
|
implemented by generic | |
|
||
|
|
driver under | Acpi/AcpiTableDxe | SmbiosDxe
|
||
|
|
"MdeModulePkg/Universal" | |
|
||
|
|
-------------------------+-------------------------+-------------------------
|
||
|
|
default tables available | yes | [RHEL] yes, Type0 and
|
||
|
|
for earlier QEMU machine | | Type1 tables
|
||
|
|
types, with hot-patching | |
|
||
|
|
-------------------------+-------------------------+-------------------------
|
||
|
|
tables fetched in Xen | yes | yes
|
||
|
|
domUs | |
|
||
|
|
|
||
|
|
Platform-specific boot policy
|
||
|
|
.............................
|
||
|
|
|
||
|
|
OVMF's BDS (Boot Device Selection) phase is implemented by
|
||
|
|
IntelFrameworkModulePkg/Universal/BdsDxe. Roughly speaking, this large driver:
|
||
|
|
|
||
|
|
- provides the EFI BDS architectural protocol (which DXE transfers control to
|
||
|
|
after dispatching all DXE drivers),
|
||
|
|
|
||
|
|
- connects drivers to devices,
|
||
|
|
|
||
|
|
- enumerates boot devices,
|
||
|
|
|
||
|
|
- auto-generates boot options,
|
||
|
|
|
||
|
|
- provides "BIOS setup" screens, such as:
|
||
|
|
|
||
|
|
- Boot Manager, for booting an option,
|
||
|
|
|
||
|
|
- Boot Maintenance Manager, for adding, deleting, and reordering boot
|
||
|
|
options, changing console properties etc,
|
||
|
|
|
||
|
|
- Device Manager, where devices can register configuration forms, including
|
||
|
|
|
||
|
|
- Secure Boot configuration forms,
|
||
|
|
|
||
|
|
- OVMF's Platform Driver form (see under PlatformDxe).
|
||
|
|
|
||
|
|
Firmware that includes the "IntelFrameworkModulePkg/Universal/BdsDxe" driver
|
||
|
|
can customize its behavior by providing an instance of the PlatformBdsLib
|
||
|
|
library class. The driver links against this platform library, and the
|
||
|
|
platform library can call Intel's BDS utility functions from
|
||
|
|
"IntelFrameworkModulePkg/Library/GenericBdsLib".
|
||
|
|
|
||
|
|
OVMF's PlatformBdsLib instance can be found in
|
||
|
|
"OvmfPkg/Library/PlatformBdsLib". The main function where the BdsDxe driver
|
||
|
|
enters the library is PlatformBdsPolicyBehavior(). We mention two OVMF
|
||
|
|
particulars here.
|
||
|
|
|
||
|
|
(1) OVMF is capable of loading kernel images directly from fw_cfg, matching
|
||
|
|
QEMU's -kernel, -initrd, and -append command line options. This feature is
|
||
|
|
useful for rapid, repeated Linux kernel testing, and is implemented in the
|
||
|
|
following call tree:
|
||
|
|
|
||
|
|
PlatformBdsPolicyBehavior() [OvmfPkg/Library/PlatformBdsLib/BdsPlatform.c]
|
||
|
|
TryRunningQemuKernel() [OvmfPkg/Library/PlatformBdsLib/QemuKernel.c]
|
||
|
|
LoadLinux*() [OvmfPkg/Library/LoadLinuxLib/Linux.c]
|
||
|
|
|
||
|
|
OvmfPkg/Library/LoadLinuxLib ports the efilinux bootloader project into
|
||
|
|
OvmfPkg.
|
||
|
|
|
||
|
|
(2) OVMF seeks to comply with the boot order specification passed down by QEMU
|
||
|
|
over fw_cfg.
|
||
|
|
|
||
|
|
(a) About Boot Modes
|
||
|
|
|
||
|
|
During the PEI phase, OVMF determines and stores the Boot Mode in the
|
||
|
|
PHIT HOB (already mentioned in "S3 (suspend to RAM and resume)"). The
|
||
|
|
boot mode is supposed to influence the rest of the system, for example it
|
||
|
|
distinguishes S3 resume (BOOT_ON_S3_RESUME) from a "normal" boot.
|
||
|
|
|
||
|
|
In general, "normal" boots can be further differentiated from each other;
|
||
|
|
for example for speed reasons. When the firmware can tell during PEI that
|
||
|
|
the chassis has not been opened since last power-up, then it might want
|
||
|
|
to save time by not connecting all devices and not enumerating all boot
|
||
|
|
options from scratch; it could just rely on the stored results of the
|
||
|
|
last enumeration. The matching BootMode value, to be set during PEI,
|
||
|
|
would be BOOT_ASSUMING_NO_CONFIGURATION_CHANGES.
|
||
|
|
|
||
|
|
OVMF only sets one of the following two boot modes, based on CMOS
|
||
|
|
contents:
|
||
|
|
- BOOT_ON_S3_RESUME,
|
||
|
|
- BOOT_WITH_FULL_CONFIGURATION.
|
||
|
|
|
||
|
|
For BOOT_ON_S3_RESUME, please refer to "S3 (suspend to RAM and resume)".
|
||
|
|
The other boot mode supported by OVMF, BOOT_WITH_FULL_CONFIGURATION, is
|
||
|
|
an appropriate "catch-all" for a virtual machine, where hardware can
|
||
|
|
easily change from boot to boot.
|
||
|
|
|
||
|
|
(b) Auto-generation of boot options
|
||
|
|
|
||
|
|
Accordingly, when not resuming from S3 sleep (*), OVMF always connects
|
||
|
|
all devices, and enumerates all bootable devices as new boot options
|
||
|
|
(non-volatile variables called Boot####).
|
||
|
|
|
||
|
|
(*) During S3 resume, DXE is not reached, hence BDS isn't either.
|
||
|
|
|
||
|
|
The auto-enumerated boot options are stored in the BootOrder non-volatile
|
||
|
|
variable after any preexistent options. (Boot options may exist before
|
||
|
|
auto-enumeration eg. because the user added them manually with the Boot
|
||
|
|
Maintenance Manager or the efibootmgr utility. They could also originate
|
||
|
|
from an earlier auto-enumeration.)
|
||
|
|
|
||
|
|
PlatformBdsPolicyBehavior() [OvmfPkg/.../BdsPlatform.c]
|
||
|
|
TryRunningQemuKernel() [OvmfPkg/.../QemuKernel.c]
|
||
|
|
BdsLibConnectAll() [IntelFrameworkModulePkg/.../BdsConnect.c]
|
||
|
|
BdsLibEnumerateAllBootOption() [IntelFrameworkModulePkg/.../BdsBoot.c]
|
||
|
|
BdsLibBuildOptionFromHandle() [IntelFrameworkModulePkg/.../BdsBoot.c]
|
||
|
|
BdsLibRegisterNewOption() [IntelFrameworkModulePkg/.../BdsMisc.c]
|
||
|
|
//
|
||
|
|
// Append the new option number to the original option order
|
||
|
|
//
|
||
|
|
|
||
|
|
(c) Relative UEFI device paths in boot options
|
||
|
|
|
||
|
|
The handling of relative ("short-form") UEFI device paths is best
|
||
|
|
demonstrated through an example, and by quoting the UEFI 2.4A
|
||
|
|
specification.
|
||
|
|
|
||
|
|
A short-form hard drive UEFI device path could be (displaying each device
|
||
|
|
path node on a separate line for readability):
|
||
|
|
|
||
|
|
HD(1,GPT,14DD1CC5-D576-4BBF-8858-BAF877C8DF61,0x800,0x64000)/
|
||
|
|
\EFI\fedora\shim.efi
|
||
|
|
|
||
|
|
This device path lacks prefix nodes (eg. hardware or messaging type
|
||
|
|
nodes) that would lead to the hard drive. During load option processing,
|
||
|
|
the above short-form or relative device path could be matched against the
|
||
|
|
following absolute device path:
|
||
|
|
|
||
|
|
PciRoot(0x0)/
|
||
|
|
Pci(0x4,0x0)/
|
||
|
|
HD(1,GPT,14DD1CC5-D576-4BBF-8858-BAF877C8DF61,0x800,0x64000)/
|
||
|
|
\EFI\fedora\shim.efi
|
||
|
|
|
||
|
|
The motivation for this type of device path matching / completion is to
|
||
|
|
allow the user to move around the hard drive (for example, to plug a
|
||
|
|
controller in a different PCI slot, or to expose the block device on a
|
||
|
|
different iSCSI path) and still enable the firmware to find the hard
|
||
|
|
drive.
|
||
|
|
|
||
|
|
The UEFI specification says,
|
||
|
|
|
||
|
|
9.3.6 Media Device Path
|
||
|
|
9.3.6.1 Hard Drive
|
||
|
|
|
||
|
|
[...] Section 3.1.2 defines special rules for processing the Hard
|
||
|
|
Drive Media Device Path. These special rules enable a disk's location
|
||
|
|
to change and still have the system boot from the disk. [...]
|
||
|
|
|
||
|
|
3.1.2 Load Option Processing
|
||
|
|
|
||
|
|
[...] The boot manager must [...] support booting from a short-form
|
||
|
|
device path that starts with the first element being a hard drive
|
||
|
|
media device path [...]. The boot manager must use the GUID or
|
||
|
|
signature and partition number in the hard drive device path to match
|
||
|
|
it to a device in the system. If the drive supports the GPT
|
||
|
|
partitioning scheme the GUID in the hard drive media device path is
|
||
|
|
compared with the UniquePartitionGuid field of the GUID Partition
|
||
|
|
Entry [...]. If the drive supports the PC-AT MBR scheme the signature
|
||
|
|
in the hard drive media device path is compared with the
|
||
|
|
UniqueMBRSignature in the Legacy Master Boot Record [...]. If a
|
||
|
|
signature match is made, then the partition number must also be
|
||
|
|
matched. The hard drive device path can be appended to the matching
|
||
|
|
hardware device path and normal boot behavior can then be used. If
|
||
|
|
more than one device matches the hard drive device path, the boot
|
||
|
|
manager will pick one arbitrarily. Thus the operating system must
|
||
|
|
ensure the uniqueness of the signatures on hard drives to guarantee
|
||
|
|
deterministic boot behavior.
|
||
|
|
|
||
|
|
Edk2 implements and exposes the device path completion logic in the
|
||
|
|
already referenced "IntelFrameworkModulePkg/Library/GenericBdsLib"
|
||
|
|
library, in the BdsExpandPartitionPartialDevicePathToFull() function.
|
||
|
|
|
||
|
|
(d) Filtering and reordering the boot options based on fw_cfg
|
||
|
|
|
||
|
|
Once we have an "all-inclusive", partly preexistent, partly freshly
|
||
|
|
auto-generated boot option list from bullet (b), OVMF loads QEMU's
|
||
|
|
requested boot order from fw_cfg, and filters and reorders the list from
|
||
|
|
(b) with it:
|
||
|
|
|
||
|
|
PlatformBdsPolicyBehavior() [OvmfPkg/.../BdsPlatform.c]
|
||
|
|
TryRunningQemuKernel() [OvmfPkg/.../QemuKernel.c]
|
||
|
|
BdsLibConnectAll() [IntelFrameworkModulePkg/.../BdsConnect.c]
|
||
|
|
BdsLibEnumerateAllBootOption() [IntelFrameworkModulePkg/.../BdsBoot.c]
|
||
|
|
SetBootOrderFromQemu() [OvmfPkg/.../QemuBootOrder.c]
|
||
|
|
|
||
|
|
According to the (preferred) "-device ...,bootindex=N" and the (legacy)
|
||
|
|
'-boot order=drives' command line options, QEMU requests a boot order
|
||
|
|
from the firmware through the "bootorder" fw_cfg file. (For a bootindex
|
||
|
|
example, refer to the "Example qemu invocation" section.)
|
||
|
|
|
||
|
|
This fw_cfg file consists of OpenFirmware (OFW) device paths -- note: not
|
||
|
|
UEFI device paths! --, one per line. An example list is:
|
||
|
|
|
||
|
|
/pci@i0cf8/scsi@4/disk@0,0
|
||
|
|
/pci@i0cf8/ide@1,1/drive@1/disk@0
|
||
|
|
/pci@i0cf8/ethernet@3/ethernet-phy@0
|
||
|
|
|
||
|
|
OVMF filters and reorders the boot option list from bullet (b) with the
|
||
|
|
following nested loops algorithm:
|
||
|
|
|
||
|
|
new_uefi_order := <empty>
|
||
|
|
for each qemu_ofw_path in QEMU's OpenFirmware device path list:
|
||
|
|
qemu_uefi_path_prefix := translate(qemu_ofw_path)
|
||
|
|
|
||
|
|
for each boot_option in current_uefi_order:
|
||
|
|
full_boot_option := complete(boot_option)
|
||
|
|
|
||
|
|
if match(qemu_uefi_path_prefix, full_boot_option):
|
||
|
|
append(new_uefi_order, boot_option)
|
||
|
|
break
|
||
|
|
|
||
|
|
for each unmatched boot_option in current_uefi_order:
|
||
|
|
if survives(boot_option):
|
||
|
|
append(new_uefi_order, boot_option)
|
||
|
|
|
||
|
|
current_uefi_order := new_uefi_order
|
||
|
|
|
||
|
|
OVMF iterates over QEMU's OFW device paths in order, translates each to a
|
||
|
|
UEFI device path prefix, tries to match the translated prefix against the
|
||
|
|
UEFI boot options (which are completed from relative form to absolute
|
||
|
|
form for the purpose of prefix matching), and if there's a match, the
|
||
|
|
matching boot option is appended to the new boot order (which starts out
|
||
|
|
empty).
|
||
|
|
|
||
|
|
(We elaborate on the translate() function under bullet (e). The
|
||
|
|
complete() function has been explained in bullet (c).)
|
||
|
|
|
||
|
|
In addition, UEFI boot options that remain unmatched after filtering and
|
||
|
|
reordering are post-processed, and some of them "survive". Due to the
|
||
|
|
fact that OpenFirmware device paths have less expressive power than their
|
||
|
|
UEFI counterparts, some UEFI boot options are simply inexpressible (hence
|
||
|
|
unmatchable) by the nested loops algorithm.
|
||
|
|
|
||
|
|
An important example is the memory-mapped UEFI shell, whose UEFI device
|
||
|
|
path is inexpressible by QEMU's OFW device paths:
|
||
|
|
|
||
|
|
MemoryMapped(0xB,0x900000,0x10FFFFF)/
|
||
|
|
FvFile(7C04A583-9E3E-4F1C-AD65-E05268D0B4D1)
|
||
|
|
|
||
|
|
(Side remark: notice that the address range visible in the MemoryMapped()
|
||
|
|
node corresponds to DXEFV under "comprehensive memory map of OVMF"! In
|
||
|
|
addition, the FvFile() node's GUID originates from the FILE_GUID entry of
|
||
|
|
"ShellPkg/Application/Shell/Shell.inf".)
|
||
|
|
|
||
|
|
The UEFI shell can be booted by pressing ESC in OVMF on the TianoCore
|
||
|
|
splash screen, and navigating to Boot Manager | EFI Internal Shell. If
|
||
|
|
the "survival policy" was not implemented, the UEFI shell's boot option
|
||
|
|
would always be filtered out.
|
||
|
|
|
||
|
|
The current "survival policy" preserves all boot options that start with
|
||
|
|
neither PciRoot() nor HD().
|
||
|
|
|
||
|
|
(e) Translating QEMU's OpenFirmware device paths to UEFI device path
|
||
|
|
prefixes
|
||
|
|
|
||
|
|
In this section we list the (strictly heuristical) mappings currently
|
||
|
|
performed by OVMF.
|
||
|
|
|
||
|
|
The "prefix only" nature of the translation output is rooted minimally in
|
||
|
|
the fact that QEMU's OpenFirmware device paths cannot carry pathnames
|
||
|
|
within filesystems. There's no way to specify eg.
|
||
|
|
|
||
|
|
\EFI\fedora\shim.efi
|
||
|
|
|
||
|
|
in an OFW device path, therefore a UEFI device path translated from an
|
||
|
|
OFW device path can at best be a prefix (not a full match) of a UEFI
|
||
|
|
device path that ends with "\EFI\fedora\shim.efi".
|
||
|
|
|
||
|
|
- IDE disk, IDE CD-ROM:
|
||
|
|
|
||
|
|
OpenFirmware device path:
|
||
|
|
|
||
|
|
/pci@i0cf8/ide@1,1/drive@0/disk@0
|
||
|
|
^ ^ ^ ^ ^
|
||
|
|
| | | | master or slave
|
||
|
|
| | | primary or secondary
|
||
|
|
| PCI slot & function holding IDE controller
|
||
|
|
PCI root at system bus port, PIO
|
||
|
|
|
||
|
|
UEFI device path prefix:
|
||
|
|
|
||
|
|
PciRoot(0x0)/Pci(0x1,0x1)/Ata(Primary,Master,0x0)
|
||
|
|
^
|
||
|
|
fixed LUN
|
||
|
|
|
||
|
|
- Floppy disk:
|
||
|
|
|
||
|
|
OpenFirmware device path:
|
||
|
|
|
||
|
|
/pci@i0cf8/isa@1/fdc@03f0/floppy@0
|
||
|
|
^ ^ ^ ^
|
||
|
|
| | | A: or B:
|
||
|
|
| | ISA controller io-port (hex)
|
||
|
|
| PCI slot holding ISA controller
|
||
|
|
PCI root at system bus port, PIO
|
||
|
|
|
||
|
|
UEFI device path prefix:
|
||
|
|
|
||
|
|
PciRoot(0x0)/Pci(0x1,0x0)/Floppy(0x0)
|
||
|
|
^
|
||
|
|
ACPI UID (A: or B:)
|
||
|
|
|
||
|
|
- Virtio-block disk:
|
||
|
|
|
||
|
|
OpenFirmware device path:
|
||
|
|
|
||
|
|
/pci@i0cf8/scsi@6[,3]/disk@0,0
|
||
|
|
^ ^ ^ ^ ^
|
||
|
|
| | | fixed
|
||
|
|
| | PCI function corresponding to disk (optional)
|
||
|
|
| PCI slot holding disk
|
||
|
|
PCI root at system bus port, PIO
|
||
|
|
|
||
|
|
UEFI device path prefixes (dependent on the presence of a nonzero PCI
|
||
|
|
function in the OFW device path):
|
||
|
|
|
||
|
|
PciRoot(0x0)/Pci(0x6,0x0)/HD(
|
||
|
|
PciRoot(0x0)/Pci(0x6,0x3)/HD(
|
||
|
|
|
||
|
|
- Virtio-scsi disk and virtio-scsi passthrough:
|
||
|
|
|
||
|
|
OpenFirmware device path:
|
||
|
|
|
||
|
|
/pci@i0cf8/scsi@7[,3]/channel@0/disk@2,3
|
||
|
|
^ ^ ^ ^ ^
|
||
|
|
| | | | LUN
|
||
|
|
| | | target
|
||
|
|
| | channel (unused, fixed 0)
|
||
|
|
| PCI slot[, function] holding SCSI controller
|
||
|
|
PCI root at system bus port, PIO
|
||
|
|
|
||
|
|
UEFI device path prefixes (dependent on the presence of a nonzero PCI
|
||
|
|
function in the OFW device path):
|
||
|
|
|
||
|
|
PciRoot(0x0)/Pci(0x7,0x0)/Scsi(0x2,0x3)
|
||
|
|
PciRoot(0x0)/Pci(0x7,0x3)/Scsi(0x2,0x3)
|
||
|
|
|
||
|
|
- Emulated and passed-through (physical) network cards:
|
||
|
|
|
||
|
|
OpenFirmware device path:
|
||
|
|
|
||
|
|
/pci@i0cf8/ethernet@3[,2]
|
||
|
|
^ ^
|
||
|
|
| PCI slot[, function] holding Ethernet card
|
||
|
|
PCI root at system bus port, PIO
|
||
|
|
|
||
|
|
UEFI device path prefixes (dependent on the presence of a nonzero PCI
|
||
|
|
function in the OFW device path):
|
||
|
|
|
||
|
|
PciRoot(0x0)/Pci(0x3,0x0)
|
||
|
|
PciRoot(0x0)/Pci(0x3,0x2)
|
||
|
|
|
||
|
|
Virtio drivers
|
||
|
|
..............
|
||
|
|
|
||
|
|
UEFI abstracts various types of hardware resources into protocols, and allows
|
||
|
|
firmware developers to implement those protocols in device drivers. The Virtio
|
||
|
|
Specification defines various types of virtual hardware for virtual machines.
|
||
|
|
Connecting the two specifications, OVMF provides UEFI drivers for QEMU's
|
||
|
|
virtio-block, virtio-scsi, and virtio-net devices.
|
||
|
|
|
||
|
|
The following diagram presents the protocol and driver stack related to Virtio
|
||
|
|
devices in edk2 and OVMF. Each node in the graph identifies a protocol and/or
|
||
|
|
the edk2 driver that produces it. Nodes on the top are more abstract.
|
||
|
|
|
||
|
|
EFI_BLOCK_IO_PROTOCOL EFI_SIMPLE_NETWORK_PROTOCOL
|
||
|
|
[OvmfPkg/VirtioBlkDxe] [OvmfPkg/VirtioNetDxe]
|
||
|
|
| |
|
||
|
|
| EFI_EXT_SCSI_PASS_THRU_PROTOCOL |
|
||
|
|
| [OvmfPkg/VirtioScsiDxe] |
|
||
|
|
| | |
|
||
|
|
+------------------------+--------------------------+
|
||
|
|
|
|
||
|
|
VIRTIO_DEVICE_PROTOCOL
|
||
|
|
|
|
||
|
|
+---------------------+---------------------+
|
||
|
|
| |
|
||
|
|
[OvmfPkg/VirtioPciDeviceDxe] [custom platform drivers]
|
||
|
|
| |
|
||
|
|
| |
|
||
|
|
EFI_PCI_IO_PROTOCOL [OvmfPkg/Library/VirtioMmioDeviceLib]
|
||
|
|
[MdeModulePkg/Bus/Pci/PciBusDxe] direct MMIO register access
|
||
|
|
|
||
|
|
The top three drivers produce standard UEFI abstractions: the Block IO
|
||
|
|
Protocol, the Extended SCSI Pass Thru Protocol, and the Simple Network
|
||
|
|
Protocol, for virtio-block, virtio-scsi, and virtio-net devices, respectively.
|
||
|
|
|
||
|
|
Comparing these device-specific virtio drivers to each other, we can determine:
|
||
|
|
|
||
|
|
- They all conform to the UEFI Driver Model. This means that their entry point
|
||
|
|
functions don't immediately start to search for devices and to drive them,
|
||
|
|
they only register instances of the EFI_DRIVER_BINDING_PROTOCOL. The UEFI
|
||
|
|
Driver Model then enumerates devices and chains matching drivers
|
||
|
|
automatically.
|
||
|
|
|
||
|
|
- They are as minimal as possible, while remaining correct (refer to source
|
||
|
|
code comments for details). For example, VirtioBlkDxe and VirtioScsiDxe both
|
||
|
|
support only one request in flight.
|
||
|
|
|
||
|
|
In theory, VirtioBlkDxe could implement EFI_BLOCK_IO2_PROTOCOL, which allows
|
||
|
|
queueing. Similarly, VirtioScsiDxe does not support the non-blocking mode of
|
||
|
|
EFI_EXT_SCSI_PASS_THRU_PROTOCOL.PassThru(). (Which is permitted by the UEFI
|
||
|
|
specification.) Both VirtioBlkDxe and VirtioScsiDxe delegate synchronous
|
||
|
|
request handling to "OvmfPkg/Library/VirtioLib". This limitation helps keep
|
||
|
|
the implementation simple, and testing thus far seems to imply satisfactory
|
||
|
|
performance, for a virtual boot firmware.
|
||
|
|
|
||
|
|
VirtioNetDxe cannot avoid queueing, because EFI_SIMPLE_NETWORK_PROTOCOL
|
||
|
|
requires it on the interface level. Consequently, VirtioNetDxe is
|
||
|
|
significantly more complex than VirtioBlkDxe and VirtioScsiDxe. Technical
|
||
|
|
notes are provided in "OvmfPkg/VirtioNetDxe/TechNotes.txt".
|
||
|
|
|
||
|
|
- None of these drivers access hardware directly. Instead, the Virtio Device
|
||
|
|
Protocol (OvmfPkg/Include/Protocol/VirtioDevice.h) collects / extracts virtio
|
||
|
|
operations defined in the Virtio Specification, and these backend-independent
|
||
|
|
virtio device drivers go through the abstract VIRTIO_DEVICE_PROTOCOL.
|
||
|
|
|
||
|
|
IMPORTANT: the VIRTIO_DEVICE_PROTOCOL is not a standard UEFI protocol. It is
|
||
|
|
internal to edk2 and not described in the UEFI specification. It should only
|
||
|
|
be used by drivers and applications that live inside the edk2 source tree.
|
||
|
|
|
||
|
|
Currently two providers exist for VIRTIO_DEVICE_PROTOCOL:
|
||
|
|
|
||
|
|
- The first one is the "more traditional" virtio-pci backend, implemented by
|
||
|
|
OvmfPkg/VirtioPciDeviceDxe. This driver also complies with the UEFI Driver
|
||
|
|
Model. It consumes an instance of the EFI_PCI_IO_PROTOCOL, and, if the PCI
|
||
|
|
device/function under probing appears to be a virtio device, it produces a
|
||
|
|
Virtio Device Protocol instance for it. The driver translates abstract virtio
|
||
|
|
operations to PCI accesses.
|
||
|
|
|
||
|
|
- The second provider, the virtio-mmio backend, is a library, not a driver,
|
||
|
|
living in OvmfPkg/Library/VirtioMmioDeviceLib. This library translates
|
||
|
|
abstract virtio operations to MMIO accesses.
|
||
|
|
|
||
|
|
The virtio-mmio backend is only a library -- rather than a standalone, UEFI
|
||
|
|
Driver Model-compliant driver -- because the type of resource it consumes, an
|
||
|
|
MMIO register block base address, is not enumerable.
|
||
|
|
|
||
|
|
In other words, while the PCI root bridge driver and the PCI bus driver
|
||
|
|
produce instances of EFI_PCI_IO_PROTOCOL automatically, thereby enabling the
|
||
|
|
UEFI Driver Model to probe devices and stack up drivers automatically, no
|
||
|
|
such enumeration exists for MMIO register blocks.
|
||
|
|
|
||
|
|
For this reason, VirtioMmioDeviceLib needs to be linked into thin, custom
|
||
|
|
platform drivers that dispose over this kind of information. As soon as a
|
||
|
|
driver knows about the MMIO register block base addresses, it can pass each
|
||
|
|
to the library, and then the VIRTIO_DEVICE_PROTOCOL will be instantiated
|
||
|
|
(assuming a valid virtio-mmio register block of course). From that point on
|
||
|
|
the UEFI Driver Model again takes care of the chaining.
|
||
|
|
|
||
|
|
Typically, such a custom driver does not conform to the UEFI Driver Model
|
||
|
|
(because that would presuppose auto-enumeration for MMIO register blocks).
|
||
|
|
Hence it has the following responsibilities:
|
||
|
|
|
||
|
|
- it shall behave as a "wrapper" UEFI driver around the library,
|
||
|
|
|
||
|
|
- it shall know virtio-mmio base addresses,
|
||
|
|
|
||
|
|
- in its entry point function, it shall create a new UEFI handle with an
|
||
|
|
instance of the EFI_DEVICE_PATH_PROTOCOL for each virtio-mmio device it
|
||
|
|
knows the base address for,
|
||
|
|
|
||
|
|
- it shall call VirtioMmioInstallDevice() on those handles, with the
|
||
|
|
corresponding base addresses.
|
||
|
|
|
||
|
|
OVMF itself does not employ VirtioMmioDeviceLib. However, the library is used
|
||
|
|
(or has been tested as Proof-of-Concept) in the following 64-bit and 32-bit
|
||
|
|
ARM emulator setups:
|
||
|
|
|
||
|
|
- in "RTSM_VE_FOUNDATIONV8_EFI.fd" and "FVP_AARCH64_EFI.fd", on ARM Holdings'
|
||
|
|
ARM(R) v8-A Foundation Model and ARM(R) AEMv8-A Base Platform FVP
|
||
|
|
emulators, respectively:
|
||
|
|
|
||
|
|
EFI_BLOCK_IO_PROTOCOL
|
||
|
|
[OvmfPkg/VirtioBlkDxe]
|
||
|
|
|
|
||
|
|
VIRTIO_DEVICE_PROTOCOL
|
||
|
|
[ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf]
|
||
|
|
|
|
||
|
|
[OvmfPkg/Library/VirtioMmioDeviceLib]
|
||
|
|
direct MMIO register access
|
||
|
|
|
||
|
|
- in "RTSM_VE_CORTEX-A15_EFI.fd" and "RTSM_VE_CORTEX-A15_MPCORE_EFI.fd", on
|
||
|
|
"qemu-system-arm -M vexpress-a15":
|
||
|
|
|
||
|
|
EFI_BLOCK_IO_PROTOCOL EFI_SIMPLE_NETWORK_PROTOCOL
|
||
|
|
[OvmfPkg/VirtioBlkDxe] [OvmfPkg/VirtioNetDxe]
|
||
|
|
| |
|
||
|
|
+------------------+---------------+
|
||
|
|
|
|
||
|
|
VIRTIO_DEVICE_PROTOCOL
|
||
|
|
[ArmPlatformPkg/ArmVExpressPkg/ArmVExpressDxe/ArmFvpDxe.inf]
|
||
|
|
|
|
||
|
|
[OvmfPkg/Library/VirtioMmioDeviceLib]
|
||
|
|
direct MMIO register access
|
||
|
|
|
||
|
|
In the above ARM / VirtioMmioDeviceLib configurations, VirtioBlkDxe was
|
||
|
|
tested with booting Linux distributions, while VirtioNetDxe was tested with
|
||
|
|
pinging public IPv4 addresses from the UEFI shell.
|
||
|
|
|
||
|
|
Platform Driver
|
||
|
|
...............
|
||
|
|
|
||
|
|
Sometimes, elements of persistent firmware configuration are best exposed to
|
||
|
|
the user in a friendly way. OVMF's platform driver (OvmfPkg/PlatformDxe)
|
||
|
|
presents such settings on the "OVMF Platform Configuration" dialog:
|
||
|
|
|
||
|
|
- Press ESC on the TianoCore splash screen,
|
||
|
|
- Navigate to Device Manager | OVMF Platform Configuration.
|
||
|
|
|
||
|
|
At the moment, OVMF's platform driver handles only one setting: the preferred
|
||
|
|
graphics resolution. This is useful for two purposes:
|
||
|
|
|
||
|
|
- Some UEFI shell commands, like DRIVERS and DEVICES, benefit from a wide
|
||
|
|
display. Using the MODE shell command, the user can switch to a larger text
|
||
|
|
resolution (limited by the graphics resolution), and see the command output
|
||
|
|
in a more easily consumable way.
|
||
|
|
|
||
|
|
[RHEL] The list of text modes available to the MODE command is also limited
|
||
|
|
by ConSplitterDxe (found under MdeModulePkg/Universal/Console).
|
||
|
|
ConSplitterDxe builds an intersection of text modes that are
|
||
|
|
simultaneously supported by all consoles that ConSplitterDxe
|
||
|
|
multiplexes console output to.
|
||
|
|
|
||
|
|
In practice, the strongest text mode restriction comes from
|
||
|
|
TerminalDxe, which provides console I/O on serial ports. TerminalDxe
|
||
|
|
has a very limited built-in list of text modes, heavily pruning the
|
||
|
|
intersection built by ConSplitterDxe, and made available to the MODE
|
||
|
|
command.
|
||
|
|
|
||
|
|
On the Red Hat Enterprise Linux 7.1 host, TerminalDxe's list of modes
|
||
|
|
has been extended with text resolutions that match the Spice QXL GPU's
|
||
|
|
common graphics resolutions. This way a "full screen" text mode should
|
||
|
|
always be available in the MODE command.
|
||
|
|
|
||
|
|
- The other advantage of controlling the graphics resolution lies with UEFI
|
||
|
|
operating systems that don't (yet) have a native driver for QEMU's virtual
|
||
|
|
video cards -- eg. the Spice QXL GPU. Such OSes may choose to inherit the
|
||
|
|
properties of OVMF's EFI_GRAPHICS_OUTPUT_PROTOCOL (provided by
|
||
|
|
OvmfPkg/QemuVideoDxe, see later).
|
||
|
|
|
||
|
|
Although the display can be used at runtime in such cases, by direct
|
||
|
|
framebuffer access, its properties, for example, the resolution, cannot be
|
||
|
|
modified. The platform driver allows the user to select the preferred GOP
|
||
|
|
resolution, reboot, and let the guest OS inherit that preferred resolution.
|
||
|
|
|
||
|
|
The platform driver has three access points: the "normal" driver entry point, a
|
||
|
|
set of HII callbacks, and a GOP installation callback.
|
||
|
|
|
||
|
|
(1) Driver entry point: the PlatformInit() function.
|
||
|
|
|
||
|
|
(a) First, this function loads any available settings, and makes them take
|
||
|
|
effect. For the preferred graphics resolution in particular, this means
|
||
|
|
setting the following PCDs:
|
||
|
|
|
||
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoHorizontalResolution
|
||
|
|
gEfiMdeModulePkgTokenSpaceGuid.PcdVideoVerticalResolution
|
||
|
|
|
||
|
|
These PCDs influence the GraphicsConsoleDxe driver (located under
|
||
|
|
MdeModulePkg/Universal/Console), which switches to the preferred
|
||
|
|
graphics mode, and produces EFI_SIMPLE_TEXT_OUTPUT_PROTOCOLs on GOPs:
|
||
|
|
|
||
|
|
EFI_SIMPLE_TEXT_OUTPUT_PROTOCOL
|
||
|
|
[MdeModulePkg/Universal/Console/GraphicsConsoleDxe]
|
||
|
|
|
|
||
|
|
EFI_GRAPHICS_OUTPUT_PROTOCOL
|
||
|
|
[OvmfPkg/QemuVideoDxe]
|
||
|
|
|
|
||
|
|
EFI_PCI_IO_PROTOCOL
|
||
|
|
[MdeModulePkg/Bus/Pci/PciBusDxe]
|
||
|
|
|
||
|
|
(b) Second, the driver entry point registers the user interface, including
|
||
|
|
HII callbacks.
|
||
|
|
|
||
|
|
(c) Third, the driver entry point registers a GOP installation callback.
|
||
|
|
|
||
|
|
(2) HII callbacks and the user interface.
|
||
|
|
|
||
|
|
The Human Interface Infrastructure (HII) "is a set of protocols that allow
|
||
|
|
a UEFI driver to provide the ability to register user interface and
|
||
|
|
configuration content with the platform firmware".
|
||
|
|
|
||
|
|
OVMF's platform driver:
|
||
|
|
|
||
|
|
- provides a static, basic, visual form (PlatformForms.vfr), written in the
|
||
|
|
Visual Forms Representation language,
|
||
|
|
|
||
|
|
- includes a UCS-16 encoded message catalog (Platform.uni),
|
||
|
|
|
||
|
|
- includes source code that dynamically populates parts of the form, with
|
||
|
|
the help of MdeModulePkg/Library/UefiHiiLib -- this library simplifies
|
||
|
|
the handling of IFR (Internal Forms Representation) opcodes,
|
||
|
|
|
||
|
|
- processes form actions that the user takes (Callback() function),
|
||
|
|
|
||
|
|
- loads and saves platform configuration in a private, non-volatile
|
||
|
|
variable (ExtractConfig() and RouteConfig() functions).
|
||
|
|
|
||
|
|
The ExtractConfig() HII callback implements the following stack of
|
||
|
|
conversions, for loading configuration and presenting it to the user:
|
||
|
|
|
||
|
|
MultiConfigAltResp -- form engine / HII communication
|
||
|
|
^
|
||
|
|
|
|
||
|
|
[BlockToConfig]
|
||
|
|
|
|
||
|
|
MAIN_FORM_STATE -- binary representation of form/widget
|
||
|
|
^ state
|
||
|
|
|
|
||
|
|
[PlatformConfigToFormState]
|
||
|
|
|
|
||
|
|
PLATFORM_CONFIG -- accessible to DXE and UEFI drivers
|
||
|
|
^
|
||
|
|
|
|
||
|
|
[PlatformConfigLoad]
|
||
|
|
|
|
||
|
|
UEFI non-volatile variable -- accessible to external utilities
|
||
|
|
|
||
|
|
The layers are very similar for the reverse direction, ie. when taking
|
||
|
|
input from the user, and saving the configuration (RouteConfig() HII
|
||
|
|
callback):
|
||
|
|
|
||
|
|
ConfigResp -- form engine / HII communication
|
||
|
|
|
|
||
|
|
[ConfigToBlock]
|
||
|
|
|
|
||
|
|
v
|
||
|
|
MAIN_FORM_STATE -- binary representation of form/widget
|
||
|
|
| state
|
||
|
|
[FormStateToPlatformConfig]
|
||
|
|
|
|
||
|
|
v
|
||
|
|
PLATFORM_CONFIG -- accessible to DXE and UEFI drivers
|
||
|
|
|
|
||
|
|
[PlatformConfigSave]
|
||
|
|
|
|
||
|
|
v
|
||
|
|
UEFI non-volatile variable -- accessible to external utilities
|
||
|
|
|
||
|
|
(3) When the platform driver starts, a GOP may not be available yet. Thus the
|
||
|
|
driver entry point registers a callback (the GopInstalled() function) for
|
||
|
|
GOP installations.
|
||
|
|
|
||
|
|
When the first GOP is produced (usually by QemuVideoDxe, or potentially by
|
||
|
|
a third party video driver), PlatformDxe retrieves the list of graphics
|
||
|
|
modes the GOP supports, and dynamically populates the drop-down list of
|
||
|
|
available resolutions on the form. The GOP installation callback is then
|
||
|
|
removed.
|
||
|
|
|
||
|
|
Video driver
|
||
|
|
............
|
||
|
|
|
||
|
|
OvmfPkg/QemuVideoDxe is OVMF's built-in video driver. We can divide its
|
||
|
|
services in two parts: graphics output protocol (primary), and Int10h (VBE)
|
||
|
|
shim (secondary).
|
||
|
|
|
||
|
|
(1) QemuVideoDxe conforms to the UEFI Driver Model; it produces an instance of
|
||
|
|
the EFI_GRAPHICS_OUTPUT_PROTOCOL (GOP) on each PCI display that it supports
|
||
|
|
and is connected to:
|
||
|
|
|
||
|
|
EFI_GRAPHICS_OUTPUT_PROTOCOL
|
||
|
|
[OvmfPkg/QemuVideoDxe]
|
||
|
|
|
|
||
|
|
EFI_PCI_IO_PROTOCOL
|
||
|
|
[MdeModulePkg/Bus/Pci/PciBusDxe]
|
||
|
|
|
||
|
|
It supports the following QEMU video cards:
|
||
|
|
|
||
|
|
- Cirrus 5430 ("-device cirrus-vga"),
|
||
|
|
- Standard VGA ("-device VGA"),
|
||
|
|
- QXL VGA ("-device qxl-vga", "-device qxl").
|
||
|
|
|
||
|
|
For Cirrus the following resolutions and color depths are available:
|
||
|
|
640x480x32, 800x600x32, 1024x768x24. On stdvga and QXL a long list of
|
||
|
|
resolutions is available. The list is filtered against the frame buffer
|
||
|
|
size during initialization.
|
||
|
|
|
||
|
|
The size of the QXL VGA compatibility framebuffer can be changed with the
|
||
|
|
|
||
|
|
-device qxl-vga,vgamem_mb=$NUM_MB
|
||
|
|
|
||
|
|
QEMU option. If $NUM_MB exceeds 32, then the following is necessary
|
||
|
|
instead:
|
||
|
|
|
||
|
|
-device qxl-vga,vgamem_mb=$NUM_MB,ram_size_mb=$((NUM_MB*2))
|
||
|
|
|
||
|
|
because the compatibility framebuffer can't cover more than half of PCI BAR
|
||
|
|
#0. The latter defaults to 64MB in size, and is controlled by the
|
||
|
|
"ram_size_mb" property.
|
||
|
|
|
||
|
|
(2) When QemuVideoDxe binds the first Standard VGA or QXL VGA device, and there
|
||
|
|
is no real VGA BIOS present in the C to F segments (which could originate
|
||
|
|
from a legacy PCI option ROM -- refer to "Compatibility Support Module
|
||
|
|
(CSM)"), then QemuVideoDxe installs a minimal, "fake" VGA BIOS -- an Int10h
|
||
|
|
(VBE) "shim".
|
||
|
|
|
||
|
|
The shim is implemented in 16-bit assembly in
|
||
|
|
"OvmfPkg/QemuVideoDxe/VbeShim.asm". The "VbeShim.sh" shell script assembles
|
||
|
|
it and formats it as a C array ("VbeShim.h") with the help of the "nasm"
|
||
|
|
utility. The driver's InstallVbeShim() function copies the shim in place
|
||
|
|
(the C segment), and fills in the VBE Info and VBE Mode Info structures.
|
||
|
|
The real-mode 10h interrupt vector is pointed to the shim's handler.
|
||
|
|
|
||
|
|
The shim is (correctly) irrelevant and invisible for all UEFI operating
|
||
|
|
systems we know about -- except Windows Server 2008 R2 and other Windows
|
||
|
|
operating systems in that family.
|
||
|
|
|
||
|
|
Namely, the Windows 2008 R2 SP1 (and Windows 7) UEFI guest's default video
|
||
|
|
driver dereferences the real mode Int10h vector, loads the pointed-to
|
||
|
|
handler code, and executes what it thinks to be VGA BIOS services in an
|
||
|
|
internal real-mode emulator. Consequently, video mode switching used not to
|
||
|
|
work in Windows 2008 R2 SP1 when it ran on the "pure UEFI" build of OVMF,
|
||
|
|
making the guest uninstallable. Hence the (otherwise optional, non-default)
|
||
|
|
Compatibility Support Module (CSM) ended up a requirement for running such
|
||
|
|
guests.
|
||
|
|
|
||
|
|
The hard dependency on the sophisticated SeaBIOS CSM and the complex
|
||
|
|
supporting edk2 infrastructure, for enabling this family of guests, was
|
||
|
|
considered suboptimal by some members of the upstream community,
|
||
|
|
|
||
|
|
[RHEL] and was certainly considered a serious maintenance disadvantage for
|
||
|
|
Red Hat Enterprise Linux 7.1 hosts.
|
||
|
|
|
||
|
|
Thus, the shim has been collaboratively developed for the Windows 7 /
|
||
|
|
Windows Server 2008 R2 family. The shim provides a real stdvga / QXL
|
||
|
|
implementation for the few services that are in fact necessary for the
|
||
|
|
Windows 2008 R2 SP1 (and Windows 7) UEFI guest, plus some "fakes" that the
|
||
|
|
guest invokes but whose effect is not important. The only supported mode is
|
||
|
|
1024x768x32, which is enough to install the guest and then upgrade its
|
||
|
|
video driver to the full-featured QXL XDDM one.
|
||
|
|
|
||
|
|
The C segment is not present in the UEFI memory map prepared by OVMF.
|
||
|
|
Memory space that would cover it is never added (either in PEI, in the form
|
||
|
|
of memory resource descriptor HOBs, or in DXE, via gDS->AddMemorySpace()).
|
||
|
|
This way the handler body is invisible to all other UEFI guests, and the
|
||
|
|
rest of edk2.
|
||
|
|
|
||
|
|
The Int10h real-mode IVT entry is covered with a Boot Services Code page,
|
||
|
|
making that too inaccessible to the rest of edk2. Due to the allocation
|
||
|
|
type, UEFI guest OSes different from the Windows Server 2008 family can
|
||
|
|
reclaim the page at zero. (The Windows 2008 family accesses that page
|
||
|
|
regardless of the allocation type.)
|
||
|
|
|
||
|
|
Afterword
|
||
|
|
---------
|
||
|
|
|
||
|
|
After the bulk of this document was written in July 2014, OVMF development has
|
||
|
|
not stopped. To name two significant code contributions from the community: in
|
||
|
|
January 2015, OVMF runs on the "q35" machine type of QEMU, and it features a
|
||
|
|
driver for Xen paravirtual block devices (and another for the underlying Xen
|
||
|
|
bus).
|
||
|
|
|
||
|
|
Furthermore, a dedicated virtualization platform has been contributed to
|
||
|
|
ArmPlatformPkg that plays a role parallel to OvmfPkg's. It targets the "virt"
|
||
|
|
machine type of qemu-system-arm and qemu-system-aarch64. Parts of OvmfPkg are
|
||
|
|
being refactored and modularized so they can be reused in
|
||
|
|
"ArmPlatformPkg/ArmVirtualizationPkg/ArmVirtualizationQemu.dsc".
|