From KVM
(add and describe the qemu wrapper script I use on RHEL-6.4 for development)
(Update guest status: F18, F19, RHEL-6.3, RHEL-6.4, Win8, Win2012Server)
Line 199: Line 199:
== Tested guest OS'en ==
== Tested guest OS'en ==
=== Apparently working nicely ===
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</li>
<li>'''Fedora 18''' (XFCE spin tested). When Fedora 18 was released, it co-operated with, and recognized Secure Boot. However some time later the signature verification algorithm changed in TianoCore, and currently OVMF doesn't accept the signatures on Fedora 18 shim. (Fedora 18 works fine on top of OVMF otherwise, when Secure Boot is disabled.)</li>
<li>RHEL-6.3. (Its grub does not support booting from a virtio-blk disk. See [[#Making guests use it]] how to specify a virtio-scsi boot disk.)</li>
<li>'''Fedora 19''' (XFCE spin tested). It supports Secure Boot on current OVMF. See [ Red Hat Bugzilla 963361 comment 9] and subsequent comments for the setup. In order to transfer certificates from host to guest (for key enrollment), it is recommended to prepare a disk image with a [ libguestfs] utility, like <code>guestfish</code> or <code>guestmount</code>, and attach it to the virtual machine.</li>
<li>Windows 8 Consumer Preview Build 8250. [[#Confirmation of secure boot in Windows 8 Consumer Preview Build 8250|Secure boot tested]] as well. The fix for qemu-kvm [ RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>'''RHEL-6.3''' and '''RHEL-6.4'''. The <code>grub-efi</code> releases in these RHEL-6 minor releases don't support booting from a virtio-blk disk. Virtio-scsi is supported however (see libvirt XML configuration above). Grub-efi in a future RHEL-6 minor release should hopefully support virtio-blk as well, see [ Red Hat Bugzilla 916016].</li>
<li>Reportedly, Windows Server 2012.</li>
<li>'''Windows 8'''. In order to test Secure Boot, enroll the keys from [ James Bottomley's blog], [ start PowerShell as an administrator], then [ verify Secure Boot].</li>
<li>'''Windows Server 2012''', reportedly.</li>
Line 293: Line 292:
=== Confirmation of secure boot in Fedora 18 ===
(This is a write-up of an earlier test.)
<li>I rebuilt OVMF with secure boot support.</li>
<li>I downloaded the x86_64 binary RPM for [ pesign-0.10-5.fc18] and extracted the <code>/etc/pki/pesign</code> directory to <code>$HOME/tmp/f18-keys</code>.</li>
<li>I extracted two certificates in DER format, standing in <code>$HOME/tmp</code>:
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
<li>I created a 64MB zero file,</li>
<li>set up <code>/dev/loop1</code> on it,</li>
<li>created an MBR partition table with one 0x0c partition (cfdisk),</li>
<li>(maybe ran <code>kpartx -a /dev/loop1</code>,)</li>
<li>formatted <code>/dev/mapper/loop1p1</code> as FAT32 with mkdosfs,</li>
<li>mounted it, created a directory called <code>Red Hat Secure Boot Keys</code>,</li>
<li>copied the output files from the previous step there.</li>
<li>NOTE: libguestfs / guestfish is a <em>much</em> better way to do the same.
<li>I attached the above image file as second disk to my preexistent
guest while it was shut down.</li>
<li>I started the guest.</li>
<li>As soon as the TianoCore splash screen showed, I entered the setup
menu and selected <code>Device Manager | Secure Boot Options</code>,</li>
<li>enrolled <code>RedHatTestCA.der</code> as PK.</li>
<li>enrolled <code>RedHatTestCertificate.der</code> as one KEK and one DB entry,</li>
<li>made sure <code>shim.efi</code> from the first disk was the first boot option in <code>Boot Maintenance Manager | Boot Options</code>,</li>
<li>allowed the boot to continue.</li>
<code>shim.efi</code> printed <code>Binary is whitelisted</code>. grub2 printed <code>secure boot forbids insmod</code> four times. The F18 XFCE GUI started. The guest dmesg contains
[    0.000000] Secure boot enabled
OVMF secure boot configuration (enrolled keys etc) don't persist
across guest shutdown (maybe not even across in-guest reboot); OVMF
reverts to non-secure boot. Copying the certificates to the F18 boot
partition didn't change this. What's more, when OVMF is built with
Secure Boot support, even the boot order saved from last time is
forgotten and default options are regenerated (even with no keys enrolled).
=== Confirmation of secure boot in Windows 8 Consumer Preview Build 8250 ===
(This is also a write-up of an earlier test.)
Basically re-executed [[#Confirmation of secure boot in Fedora 18]], with the following changes:
<li>I downloaded the platform key, the key exchange key, and three DB entries from [ James Bottomley's blog].</li>
<li>Once inside the guest, I [ started PowerShell as an administrator] and
then [ verified that Secure Boot was enabled].</li>

Revision as of 12:57, 15 June 2013


OVMF "is a project to enable UEFI support for Virtual Machines". This page tries to give yet another mini-howto about playing with OVMF boot firmware in qemu-kvm virtual machines plus libvirt, deferring heavily to the TianoCore upstream wiki. Do mercilessly edit any inaccuracies or wrong statements.

This page is written as of edk2 svn rev 14423 (virtio-blk, virtio-scsi and virtio-net are supported, and several guests can be booted with, and recognize secure boot). For using OVMF directly with the qemu command line, refer to the README; this page tries to detail OVMF usage under (RHEL-6.4) libvirt.

The recommended way for testing OVMF is installing Gerd Hoffman's RPM packages from his repo at, using yum. (The package to install is edk2.git-ovmf-x64; yum will pull in several dependencies from the repo.)

The firmware images are located in the /usr/share/edk2.git/ovmf-x64 directory. OVMF-pure-efi.fd is a "pure UEFI" image, while OVMF-with-csm.fd includes the Compatibility Support Module (CSM) build of SeaBIOS. bios.bin is a symlink to the latter. Both images support Secure Boot.

Building from source

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the TianoCore wiki.

Frequent rebuilds

For developers it is recommended to create a branch called base_config or something similar off the master branch (in the git svn or plain git clone), capture the config steps described here in commits (including setting up a reasonable .gitignore file), and keep rebasing base_config after git svn rebase --use-log-author / git pull commands. Fork/rebase your own development branches off/to base_config.

The very first time you build the tree, and after git clean -fdx commands, you must (re)build BaseTools with make -C "$EDK_TOOLS_PATH". (You're going to have that variable set in your environment after sourcing in the root project dir; see the TianoCore Wiki again.)

One-off builds

OvmfPkg/ takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is -n THREADNUMBER, which enables parallel make.

-D FLAG options control optional build features/aspects; among other things, verbosity of OVMF's debug log. Consult OvmfPkg/, OvmfPkg/README, the OvmfPkg/*.dsc and OvmfPkg/*.fdf files, and Gerd's SRPMs.

Using the firmware image with libvirt

The boot firmware is set in the domain XML file under the /domain/os/loader element.

Neither virt-manager nor virt-install seem to expose this XML node on RHEL-6.4. The following list of commands is one workaround. The EMULATOR bit is discussed later -- it is useful to have a wrapper script in place, between libvirt and qemu, to add custom options.

# "configuration"

# create a domain XML template for guest installation:
# - 4 VCPUs, 4G RAM
# - virtio target disk, 25 GB in size
# - first IDE CD-ROM has install disk
# - second IDE CD-ROM has virtio driver disk
#   (should only be necessary for proprietary guests without built-in drivers)
virt-install                                                                 \
    --connect=qemu:///system                                                 \
    --name=$NAME                                                             \
    --ram=4096                                                               \
    --arch=x86_64                                                            \
    --machine=rhel6.4.0                                                      \
    --vcpus=4                                                                \
    --boot=cdrom,hd                                                          \
    --disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2                 \
    --disk=path=$INSTALL_ISO,device=cdrom,bus=ide,perms=ro,format=raw        \
    --disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw         \
    --print-step=1                                                           \
| xmlstarlet ed -u /domain/devices/emulator                     -v $EMULATOR \
                -s /domain/os                 -t elem -n loader -v $LOADER   \

# Import the template to libvirt
virsh define template.xml

# Now customize the guest further with "virsh edit" or inside virt-manager,
# then start the installation.

For a virtio-scsi disk, apply the following changes:

  1. in the TARGET_DISK specification, replace bus=virtio with bus=scsi,
  2. append the following options to the xmlstarlet command line:
                    -s /domain/devices            -t elem -n controller -v ''          \
                    -s /domain/devices/controller -t attr -n type       -v scsi        \
                    -s /domain/devices/controller -t attr -n model      -v virtio-scsi \

qemu wrapper script under libvirt

Libvirt (and its frontends, eg. virsh and virt-manager) provide a convenient way to manage virtual machines. However some qemu command line options are not directly exposed (at least not on a RHEL-6.4 host) that would prove useful otherwise. A script that wraps qemu and plays the emulator role for libvirt allows extra flexibility. On the other side of the coin, it may introduce extra confusion, so use with care.

The full path to the wrapper script is specified in the /domain/devices/emulator element of the libvirt guest XML.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator binary. See chcon --reference.

(Needless to say, never use a wrapper script in production.)

An example script follows.

set -e -C -u

# Operating modes:
# - AD_HOC: use local OVMF & SeaVGABIOS build, ignore iPXE roms,
# - AD_HOC_IPXE: same, but make use of ad-hoc iPXE roms,
# - KRAXEL_RPMS: use Kraxel's RPMs whole-sale

# Location of ad-hoc ROMs.

# Root installation directory of Kraxel's RPMs.

# Whether to load extra SMBIOS tables.

# Argument array constructed for qemu-kvm.
  for I in "$@"; do

# -vga cirrus found in AD_HOC* modes

# -name XXX found; XXX saved in $NAME

# previous argument processed
for ARG in "$@"; do
  if [ x-vga = x"$LAST" ] && [ cirrus = "$ARG" ] \
      && ([ AD_HOC = "$MODE" ] || [ AD_HOC_IPXE = "$MODE" ]); then
    append "$ARG"
  elif [ x-device = x"$LAST" ] && [ AD_HOC_IPXE = "$MODE" ]; then
    case "$ARG" in
        append "$ARG,romfile=$AD_HOC_PATH/efi-roms/efi-e1000.rom"
        append "$ARG,romfile=$AD_HOC_PATH/efi-roms/efi-ne2k_pci.rom"
        append "$ARG,romfile=$AD_HOC_PATH/efi-roms/efi-pcnet.rom"
        append "$ARG,romfile=$AD_HOC_PATH/efi-roms/efi-rtl8139.rom"
        append "$ARG,romfile=$AD_HOC_PATH/efi-roms/efi-virtio.rom"
        append "$ARG"
  elif [ x-bios = x"$LAST" ] && [ KRAXEL_RPMS = "$MODE" ]; then
    append "$KRAXEL_PATH/bios.bin" -L "$KRAXEL_PATH"
  elif [ x-name = x"$LAST" ]; then
    append "$ARG"
    append "$ARG"


if [ -n "$NAME" ]; then
  append -debugcon file:/tmp/"$NAME".debug -global isa-debugcon.iobase=0x402 \
      -global PIIX4_PM.disable_s3=0 -global PIIX4_PM.disable_s4=0

  if [ 0 -ne $SMBIOS_EXTRA ]; then
    append -smbios file=$AD_HOC_PATH/smbios/type3

  if [[ x"$NAME" = xovmf.win2k8* ]] && [ 0 -ne $AD_HOC_CIRRUS ]; then
    append -global cirrus-vga.romfile=$AD_HOC_PATH/vgabios-cirrus.csm.bin

exec /usr/libexec/qemu-kvm "${NEW_ARGS[@]}"

This particular script accounts for libvirt invoking the emulator in two forms. XML validation after virsh edit seems to invoke the emulator for verification purposes only, without the -name option. In this case no debug file should be created / rewritten, plus other static options are useless. When libvirt starts the guest, the -name option is present, the script constructs the logfile's name from the corresponding option-argument, and adds some extra static options.

In more detail, the script supports three "operating modes".

  1. The KRAXEL_RPMS mode is the recommended one for qemu-1.5+. This mode overrides the /domain/os/loader element of the guest XML, and uses the OVMF firmware and any other required files from Gerd's package. Notably, EFI drivers for the emulated / virtio NICs from the iPXE project will be available in the guest as option ROMs.
  2. The AD_HOC mode serves development purposes. It disables any iPXE NIC drivers on qemu versions under 1.5 (so that the built-in VirtioNetDxe driver can be tested), lets /domain/os/loader (= custom OVMF build) take effect, and specifies a custom SeaVGABIOS binary for Windows 2008 R2 guests (based on their name). The Windows 2008 R2 guest is discussed below some more.
  3. The AD_HOC_IPXE mode is the same, a development helper, except it gives priority to custom iPXE NIC drivers. (Consult OvmfPkg/README for networking options.)

The static options enable S3/S4 in RHEL-6.4 qemu, and set the location of OVMF's debug log.

On an SELinux enabled system, a new instance of the same guest will be seclabelled differently from the previous instance, and will fail to overwrite the debug log produced by the previous instance. This could be worked around perhaps by reconfiguring libvirt's labelling practices for the guest, or changing the SELinux profile, or (horribile dictu) flipping SELinux to permissive. Removing the debug file manually before starting the next instance of the guest is simplest.

Tested guest OS'en

  • Fedora 18 (XFCE spin tested). When Fedora 18 was released, it co-operated with, and recognized Secure Boot. However some time later the signature verification algorithm changed in TianoCore, and currently OVMF doesn't accept the signatures on Fedora 18 shim. (Fedora 18 works fine on top of OVMF otherwise, when Secure Boot is disabled.)
  • Fedora 19 (XFCE spin tested). It supports Secure Boot on current OVMF. See Red Hat Bugzilla 963361 comment 9 and subsequent comments for the setup. In order to transfer certificates from host to guest (for key enrollment), it is recommended to prepare a disk image with a libguestfs utility, like guestfish or guestmount, and attach it to the virtual machine.
  • RHEL-6.3 and RHEL-6.4. The grub-efi releases in these RHEL-6 minor releases don't support booting from a virtio-blk disk. Virtio-scsi is supported however (see libvirt XML configuration above). Grub-efi in a future RHEL-6 minor release should hopefully support virtio-blk as well, see Red Hat Bugzilla 916016.
  • Windows 8. In order to test Secure Boot, enroll the keys from James Bottomley's blog, start PowerShell as an administrator, then verify Secure Boot.
  • Windows Server 2012, reportedly.

Windows Server 2008 R2 SP1

This guest does not work correctly. Its UEFI installer is composed of several programs, some being UEFI applications, and the last layer being the Windows Pre-Installation Environment, running on the Windows 2008 R2 kernel.

The UEFI applications before the last layer correctly use the OVMF GOP (graphics output protocol), which drives the emulated Cirrus 5446 video card. Unfortunately, the last layer (WinPE) has a hard dependency on VGA BIOS interrupt 0x10, which is not provided by any OVMF CSM (compatibility support module) as of now.

This hard dependency is a Windows 2008 R2 bug; the WinPE layer should (actively) inherit the linear framebuffer characteristics from the GOP (UEFI boot phase), and use that until the kernel-level graphics drivers are loaded.

One (quite shabby) workaround for the time being is automated installation of this OS on top of OVMF, and then connecting to it with rdesktop.

During most of the installation (ie. in the WinPE phase), nothing can be seen in the VNC window. The VM reboots several times, at which points cdboot.efi shortly displays a (visible) message, "press a key to continue booting from the installation CD". No key should be pressed, as expected, but after the timeout, cdboot.efi tends to crash, violating an edk2 framework ASSERT and falling into an infinite loop (watch the debug log).

If this happens, force off the VM, restart it, enter the OVMF setup utility, and manually set the on-hdd boot loader. The installation should resume then.

For the remote desktop connection, the IP address of the running guest can be fetched by searching /var/lib/libvirt/dnsmasq/default.leases for the guest's MAC address (which is present in its libvirt XML file).

An example AutoUnattend.xml file, and a corresponding guest XML template (to be used with virsh define) are inserted below as a base-64 encoded, xz-compressed tarball. (Unfortunately, File Upload refuses xml and xml.gz files.) The install ISO that was augmented with the AutoUnattend.xml file is named en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso, its SHA1 is D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A.

Note: the first ProductKey element in the XML is a default key from \SOURCES\PRODUCT.INI. It does not participate in product activation, it contributes to product selection at installation time.

begin-base64 600 example.tar.xz