KVM - User contributions [en]

WindowsGuestDrivers/Repository

2017-02-15T16:56:14Z

Lersek: update links to KVM Windows guest drivers upstream code

The master repository for development of the KVM Windows guest drivers is hosted on GitHub:

* Anonymous clone of repository:

git clone git://github.com/virtio-win/kvm-guest-drivers-windows.git

* [https://github.com/virtio-win/kvm-guest-drivers-windows Browse GIT repository online]

OVMF

2015-03-10T14:27:43Z

Lersek: replace stale contents with link to whitepaper

OVMF "is a project to enable UEFI support for Virtual Machines".

The earlier contents of this article have been replaced with the following link to the OVMF whitepaper:

http://www.linux-kvm.org/downloads/lersek/ovmf-whitepaper-c770f8c.txt

The whitepaper covers everything this article used to cover, and the whitepaper is much more up-to-date and extensive. Please use the History link near the bottom if you'd like to see the previous (now stale) contents.

KVM Forum 2014 BOF

2014-09-16T14:56:42Z

Lersek: add OVMF BoF

= Introduction =

We will reserve some time for people to get together and discuss
strategic decisions as well as other topics that are best solved within
smaller groups. This time can also be used for hands-on hacking
sessions.

If you are interested in organizing such a group time event, please add
it to the list *before* KVM Forum, so people have time to organize which
one they will attend.

All of these sessions will get the chance to quickly talk about results
they managed to achieve during their time in a quick "results" session.

= BoF Ideas =

== OVMF ==

=== Open Virtual Machine Firmware ===

'''Summary:''' OVMF (Open Virtual Machine Firmware) is a project to enable
UEFI support for Virtual Machines. This BoF should allow users and
developers of virtualization and/or UEFI software to discuss how OVMF fits
in the "intersection" of virt and UEFI, what it is good for, how it can be
used, how people can contribute, and how OVMF works, internally and in
combination with the other layers of the virt stack.

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.

In this BoF all areas and topics related to the overlap of virt and UEFI are
welcome (regardless of their "technical depth"), except politics and/or
historical controversy around UEFI Secure Boot. (Discussing Secure Boot per
se is fine.)

'''People:'''
* Laszlo Ersek ("organizer")
* <add your name here>

== BoF idea template ==

<pre>
=== TITLE ===

'''Summary:''' Short description of the idea

Detailed description of the idea.

'''Links:'''
* Wiki links to relevant material
* External links to mailing lists or web sites

'''People:'''
* Your Name (organizer)
* People that want to attend this session
</pre>

OVMF

2013-08-26T10:01:18Z

Lersek: specify "hd,cdrom" boot order -- makes no difference while the target disk is unpartitioned, and is preferred after completing the installation

OVMF

2013-06-20T11:33:52Z

Lersek: Gerd's packages now enable win2k8r2sp1 to work out of the box

OVMF

2013-06-15T13:44:24Z

Lersek: fix typo in Gerd's name

OVMF

2013-06-15T13:42:26Z

Lersek: update win2k8r2sp1 guest status

OVMF

2013-06-15T12:57:51Z

Lersek: Update guest status: F18, F19, RHEL-6.3, RHEL-6.4, Win8, Win2012Server

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.)

The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> 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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF here] in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase --use-log-author</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

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

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

== Using the firmware image with libvirt ==

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

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

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

=== 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 <code>/domain/devices/emulator</code> 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 <code>chcon --reference</code>.

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

An example script follows.

<pre>
#!/bin/bash
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
MODE=KRAXEL_RPMS

# Location of ad-hoc ROMs.
AD_HOC_PATH=/home/virt-images

# Root installation directory of Kraxel's RPMs.
KRAXEL_PATH=/usr/share/edk2.git/ovmf-x64

# Whether to load extra SMBIOS tables.
SMBIOS_EXTRA=0

# Argument array constructed for qemu-kvm.
NEW_ARGS=()
append()
{
for I in "$@"; do
NEW_ARGS[${#NEW_ARGS[@]}]=$I
done
}

# -vga cirrus found in AD_HOC* modes
AD_HOC_CIRRUS=0

# -name XXX found; XXX saved in $NAME
NAME=

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

LAST=$ARG
done

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
fi

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

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

This particular script accounts for libvirt invoking the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten, plus other static options are useless. When libvirt starts the guest, the <code>-name</code> 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".

<ol>
<li>The <code>KRAXEL_RPMS</code> mode is the recommended one for qemu-1.5+. This mode overrides the <code>/domain/os/loader</code> 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.</li>
<li>The <code>AD_HOC</code> 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 <code>/domain/os/loader</code> (= 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.</li>
<li>The <code>AD_HOC_IPXE</code> mode is the same, a development helper, except it gives priority to custom iPXE NIC drivers. (Consult <code>OvmfPkg/README</code> for networking options.)</li>
</ol>

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 ==

<ul>
<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>'''Fedora 19''' (XFCE spin tested). It supports Secure Boot on current OVMF. See [https://bugzilla.redhat.com/show_bug.cgi?id=963361#c9 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 [http://libguestfs.org/ libguestfs] utility, like <code>guestfish</code> or <code>guestmount</code>, and attach it to the virtual machine.</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 [https://bugzilla.redhat.com/show_bug.cgi?id=916016 Red Hat Bugzilla 916016].</li>
<li>'''Windows 8'''. In order to test Secure Boot, enroll the keys from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog], [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx start PowerShell as an administrator], then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verify Secure Boot].</li>
<li>'''Windows Server 2012''', reportedly.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

OVMF

2013-06-15T12:21:28Z

Lersek: add and describe the qemu wrapper script I use on RHEL-6.4 for development

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.)

The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> 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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF here] in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase --use-log-author</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

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

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

== Using the firmware image with libvirt ==

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

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

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

=== 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 <code>/domain/devices/emulator</code> 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 <code>chcon --reference</code>.

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

An example script follows.

<pre>
#!/bin/bash
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
MODE=KRAXEL_RPMS

# Location of ad-hoc ROMs.
AD_HOC_PATH=/home/virt-images

# Root installation directory of Kraxel's RPMs.
KRAXEL_PATH=/usr/share/edk2.git/ovmf-x64

# Whether to load extra SMBIOS tables.
SMBIOS_EXTRA=0

# Argument array constructed for qemu-kvm.
NEW_ARGS=()
append()
{
for I in "$@"; do
NEW_ARGS[${#NEW_ARGS[@]}]=$I
done
}

# -vga cirrus found in AD_HOC* modes
AD_HOC_CIRRUS=0

# -name XXX found; XXX saved in $NAME
NAME=

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

LAST=$ARG
done

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
fi

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

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

This particular script accounts for libvirt invoking the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten, plus other static options are useless. When libvirt starts the guest, the <code>-name</code> 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".

<ol>
<li>The <code>KRAXEL_RPMS</code> mode is the recommended one for qemu-1.5+. This mode overrides the <code>/domain/os/loader</code> 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.</li>
<li>The <code>AD_HOC</code> 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 <code>/domain/os/loader</code> (= 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.</li>
<li>The <code>AD_HOC_IPXE</code> mode is the same, a development helper, except it gives priority to custom iPXE NIC drivers. (Consult <code>OvmfPkg/README</code> for networking options.)</li>
</ol>

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 ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2013-06-15T11:35:27Z

Lersek: remove debug log discussion (configuration, capturing); the README deals with them

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.)

The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> 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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF here] in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase --use-log-author</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

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

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

== Using the firmware image with libvirt ==

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

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

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

=== 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).

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2013-06-15T11:24:25Z

Lersek: refresh libvirt intro

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.)

The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> 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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF here] in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase --use-log-author</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

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

<code>-D FLAG</code> options control optional build features/aspects. Consult <code>OvmfPkg/build.sh</code>, <code>OvmfPkg/README</code>, the <code>OvmfPkg/*.dsc</code> and <code>OvmfPkg/*.fdf</code> files, and Gerd's SRPMs.

== Using the firmware image with libvirt ==

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

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

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2013-06-15T11:15:27Z

Lersek: state that Gerd's binaries support Secure Boot (OpenSSL patch etc)

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.)

The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> 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 [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF here] in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase --use-log-author</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

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

<code>-D FLAG</code> options control optional build features/aspects. Consult <code>OvmfPkg/build.sh</code>, <code>OvmfPkg/README</code>, the <code>OvmfPkg/*.dsc</code> and <code>OvmfPkg/*.fdf</code> files, and Gerd's SRPMs.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2013-06-15T11:14:09Z

Lersek: update TianoCore wiki link describing build config

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.) The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> is a symlink to the latter.

== Building from source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF here] in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase --use-log-author</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

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

<code>-D FLAG</code> options control optional build features/aspects. Consult <code>OvmfPkg/build.sh</code>, <code>OvmfPkg/README</code>, the <code>OvmfPkg/*.dsc</code> and <code>OvmfPkg/*.fdf</code> files, and Gerd's SRPMs.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2013-06-15T11:10:41Z

Lersek: Reword build instructions, recommend to check the SRPMs

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.) The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> is a symlink to the latter.

== Building from source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF here] in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase --use-log-author</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

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

<code>-D FLAG</code> options control optional build features/aspects. Consult <code>OvmfPkg/build.sh</code>, <code>OvmfPkg/README</code>, the <code>OvmfPkg/*.dsc</code> and <code>OvmfPkg/*.fdf</code> files, and Gerd's SRPMs.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2013-06-15T11:04:21Z

Lersek: add intro heading

== Intro ==

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.) The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> is a symlink to the latter.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2013-06-15T11:02:39Z

Lersek: update intro text to svn r14423, plus recommend Gerd's packaging primarily

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 [https://github.com/tianocore/edk2/blob/master/OvmfPkg/README 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 http://www.kraxel.org/repos/, using yum. (The package to install is <code>edk2.git-ovmf-x64</code>; yum will pull in several dependencies from the repo.) The firmware images are located in the <code>/usr/share/edk2.git/ovmf-x64</code> directory. <code>OVMF-pure-efi.fd</code> is a "pure UEFI" image, while <code>OVMF-with-csm.fd</code> includes the Compatibility Support Module (CSM) build of SeaBIOS. <code>bios.bin</code> is a symlink to the latter.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-12-31T09:29:18Z

Lersek: add link to kraxel's qemu firmware repo

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

The yum repository at http://www.kraxel.org/repos/ provides automatically updated OVMF RPMs (among other qemu firmware binaries).

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-10-31T14:05:08Z

Lersek: formatting fix

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<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 much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-10-31T13:46:50Z

Lersek: add intra-page secure boot testing links

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). [[#Confirmation of secure boot in Fedora 18|Secure boot tested]] as well.</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>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 [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<li>set up /dev/loop1 on it,</li>
<li>created an MBR partition table with one 0x0c partition (cfdisk),</li>
<li>(maybe ran kpartx -a /dev/loop1,)</li>
<li>formatted /dev/mapper/loop1p1 as FAT32 with mkdosfs,</li>
<li>mounted it, created a directory called "Red Hat Secure Boot Keys",</li>
<li>copied the output files from the previous step there.</li>
<li>NOTE: libguestfs / guestfish is a much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-10-31T13:40:27Z

Lersek: add 'set -u' to wrapper script

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C -u

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). Secure boot tested as well.</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>Windows 8 Consumer Preview Build 8250. Secure boot tested as well. The fix for qemu-kvm [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<li>set up /dev/loop1 on it,</li>
<li>created an MBR partition table with one 0x0c partition (cfdisk),</li>
<li>(maybe ran kpartx -a /dev/loop1,)</li>
<li>formatted /dev/mapper/loop1p1 as FAT32 with mkdosfs,</li>
<li>mounted it, created a directory called "Red Hat Secure Boot Keys",</li>
<li>copied the output files from the previous step there.</li>
<li>NOTE: libguestfs / guestfish is a much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== Confirmation of secure boot in Windows 2008 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-10-31T13:36:53Z

Lersek: grammar fix

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# 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.
</pre>

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). Secure boot tested as well.</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>Windows 8 Consumer Preview Build 8250. Secure boot tested as well. The fix for qemu-kvm [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<li>set up /dev/loop1 on it,</li>
<li>created an MBR partition table with one 0x0c partition (cfdisk),</li>
<li>(maybe ran kpartx -a /dev/loop1,)</li>
<li>formatted /dev/mapper/loop1p1 as FAT32 with mkdosfs,</li>
<li>mounted it, created a directory called "Red Hat Secure Boot Keys",</li>
<li>copied the output files from the previous step there.</li>
<li>NOTE: libguestfs / guestfish is a much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== Confirmation of secure boot in Windows 2008 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-10-31T13:33:14Z

Lersek: style fix

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One potentially useful option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# Import the template into libvirt
virsh define template.xml

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

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). Secure boot tested as well.</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>Windows 8 Consumer Preview Build 8250. Secure boot tested as well. The fix for qemu-kvm [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<li>set up /dev/loop1 on it,</li>
<li>created an MBR partition table with one 0x0c partition (cfdisk),</li>
<li>(maybe ran kpartx -a /dev/loop1,)</li>
<li>formatted /dev/mapper/loop1p1 as FAT32 with mkdosfs,</li>
<li>mounted it, created a directory called "Red Hat Secure Boot Keys",</li>
<li>copied the output files from the previous step there.</li>
<li>NOTE: libguestfs / guestfish is a much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== Confirmation of secure boot in Windows 2008 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-10-31T13:30:49Z

Lersek: small style fix

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured accordingly. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One important option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# Import the template into libvirt
virsh define template.xml

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

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). Secure boot tested as well.</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>Windows 8 Consumer Preview Build 8250. Secure boot tested as well. The fix for qemu-kvm [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<li>set up /dev/loop1 on it,</li>
<li>created an MBR partition table with one 0x0c partition (cfdisk),</li>
<li>(maybe ran kpartx -a /dev/loop1,)</li>
<li>formatted /dev/mapper/loop1p1 as FAT32 with mkdosfs,</li>
<li>mounted it, created a directory called "Red Hat Secure Boot Keys",</li>
<li>copied the output files from the previous step there.</li>
<li>NOTE: libguestfs / guestfish is a much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== Confirmation of secure boot in Windows 2008 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>

OVMF

2012-10-31T13:19:27Z

Lersek: OVMF: UEFI boot firmware in qemu-kvm

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 13886 (virtio-blk and virtio-scsi are supported), with a RHEL-6.3 host and only x86_64 in mind.

If you want to skip downloading & building the SVN tree, you could try one of the prebuilt images, or rebuilding one of the SRPMs. For such packages, check out the TianoCore wiki links below, and/or http://people.redhat.com/~lersek/ovmf_pkg/. (The latter SRPM utilizes the <code>%jobs</code> RPM macro for parallel builds; don't forget to set it in your <code>~/.rpmmacros</code>.)

If you opt for RPM installation, continue at [[#Making guests use it]] afterwards.

== Downloading the source ==

Clone either the main SVN repository (git svn recommended) or one of the git mirrors listed in the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=Source_Control TianoCore wiki].

== Building it ==

The EDK2 (EFI Development Kit 2) tree has a complex, but very portable and flexible build system, called BaseTools. OVMF is one of the sub-projects inside the EDK2 tree (located in the OvmfPkg subdirectory), relying on other modules inside the tree.

When building OVMF, the build system must be configured to build OvmfPkg. Inter-module and intra-module dependencies are then handled automatically.

The build system's configuration is described in detail, rooted in [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF this] TianoCore wiki page.

=== Frequent rebuilds ===

For developers it is recommended to create a branch called <code>base_config</code> or something similar off the master branch (in the git svn or plain git clone), capture the config steps described under the above edk2 upstream link in commits (including setting up a reasonable <code>.gitignore</code> file), and keep rebasing <code>base_config</code> after <code>git svn rebase</code> / <code>git pull</code> commands. Fork/rebase your own development branches off/to <code>base_config</code>.

One possible <code>.gitignore</code> file is

<pre>
*.d
*.o
*.pyc
/BaseTools/Source/C/VfrCompile/EfiVfrParser.cpp
/BaseTools/Source/C/VfrCompile/EfiVfrParser.h
/BaseTools/Source/C/VfrCompile/Pccts/antlr/antlr
/BaseTools/Source/C/VfrCompile/Pccts/dlg/dlg
/BaseTools/Source/C/VfrCompile/VfrLexer.cpp
/BaseTools/Source/C/VfrCompile/VfrLexer.h
/BaseTools/Source/C/VfrCompile/VfrParser.dlg
/BaseTools/Source/C/VfrCompile/VfrSyntax.cpp
/BaseTools/Source/C/VfrCompile/VfrTokens.h
/BaseTools/Source/C/bin/
/BaseTools/Source/C/libs/
/Build/
/Conf/.cache/
</pre>

The very first time you build the tree, and after <code>git clean -fdx</code> commands, you must (re)build BaseTools with <code>make -C "$EDK_TOOLS_PATH"</code>. (You're going to have that variable set in your environment after sourcing <code>edksetup.sh</code> in the root project dir; see the [http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF TianoCore Wiki] again.)

=== One-off builds ===

Consult <code>OvmfPkg/build.sh</code> and <code>OvmfPkg/README</code>.

<code>OvmfPkg/build.sh</code> takes care of BaseTools, configuration (according to command line options) and the main build. One important option is <code>-n THREADNUMBER</code>, which enables parallel make. <code>-D FLAG</code> options control optional build features/aspects; one place to look up the more common ones could be the SRPM / spec file [http://people.redhat.com/~lersek/ovmf_pkg/ here].

<code>OvmfPkg/README</code> is slightly outdated; for example no separate <code>OvmfVideo.rom</code> file is produced any longer.

== Making guests use it ==

So now you have either downloaded a prebuilt binary, or installed the noarch RPM in the host, or built <code>OVMF.fd</code> yourself. This "Flash Device" file is passed to qemu-kvm with the <code>-bios</code> option (with full pathname), which is accessible in the libvirt domain XML as the <code>/domain/os/loader</code> element.

Neither <code>virt-manager</code> nor <code>virt-install</code> seem to make this option readily configurable at guest installation time in RHEL-6.3. The following list of commands is one workaround. The <code>EMULATOR</code> bit is elaborated upon under [[#qemu debug port]].

<pre>
# "configuration"
NAME=set_guest_name_here
INSTALL_ISO=/full/path/to/install/iso
DRIVER_ISO=/full/path/to/virtio/driver/iso
EMULATOR=/full/path/to/emulator
LOADER=/full/path/to/OVMF.fd

# 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)
TARGET_DISK=/var/lib/libvirt/images/"$NAME".img
virt-install \
--connect=qemu:///system \
--name=$NAME \
--ram=4096 \
--arch=x86_64 \
--machine=rhel6.3.0 \
--vcpus=4 \
--boot=cdrom,hd \
--disk=path=$TARGET_DISK,size=25,bus=virtio,format=qcow2 \
--disk=path=$DRIVER_ISO,device=cdrom,bus=ide,perms=ro,format=raw \
--disk=path=$INSTALL_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 \
>template.xml

# Import the template into libvirt
virsh define template.xml

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

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

<ol>
<li>in the <code>TARGET_DISK</code> specification, replace <code>bus=virtio</code> with <code>bus=scsi</code>,</li>
<li>append the following options to the <code>xmlstarlet</code> command line:
<pre>
-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 \
</pre>
</li>
</ol>

== Saving OVMF debug messages ==

Debug log verbosity is controlled at build time. See the <code>gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel</code> bitmask in <code>OvmfPkg/OvmfPkgX64.dsc</code>. The individual bits (<code>DEBUG_*</code> macros) are explained in <code>MdePkg/Include/Library/DebugLib.h</code>.

=== serial console ===

Debug messages are written to the qemu debug port per default (see below), but they can be redirected to the (virtual) serial console with the <code>-D DEBUG_ON_SERIAL_PORT</code> option at build time. In this case however the serial console will intermix framework debug messages with the TUI of the (U)EFI shell and other UEFI applications.

=== qemu debug port ===

This is where the debug messages are written by default, but capturing them on the host requires the <code>-debugcon DEV -global isa-debugcon.iobase=0x402</code> qemu-kvm command line switches. These can be set on a guest-by-guest basis in the libvirt VM config XML files, using [http://libvirt.org/drvqemu.html#qemucommand qemu:arg].

Alternatively, one might contemplate a qemu-kvm wrapper script like the following:

<pre>
#!/bin/bash
set -e -C

NAME=0
for ARG in "$@"; do
if [ x"$ARG" = x-name ]; then
NAME=1
elif [ $NAME -ne 0 ]; then
FNAME="${TMPDIR:-/tmp}/$ARG".debug
exec /usr/libexec/qemu-kvm "$@" \
-debugcon file:"$FNAME" -global isa-debugcon.iobase=0x402
fi
done
exec /usr/libexec/qemu-kvm "$@"
</pre>

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

The script is adapted to the fact that libvirt invokes the emulator in two forms. XML validation after <code>virsh edit</code> seems to invoke the emulator for verification purposes only, without the <code>-name</code> option. In this case no debug file should be created / rewritten. When libvirt starts the guest, the <code>-name</code> option is present, and the script constructs the logfile's name from the corresponding option-argument.

On an SELinux enabled system, the script's context should be set to that of the wrapped emulator, qemu-kvm. See <code>chcon --reference</code>.

Furthermore, 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.

(Needless to say, never do any of this in production.)

== Tested guest OS'en ==

=== Apparently working nicely ===

<ul>
<li>Fedora 18 Alpha (XFCE edition). Secure boot tested as well.</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>Windows 8 Consumer Preview Build 8250. Secure boot tested as well. The fix for qemu-kvm [https://bugzilla.redhat.com/show_bug.cgi?id=854304 RHBZ#854304] may be necessary to run this guest. (Upstream qemu contains the [http://git.qemu.org/?p=qemu.git;a=commitdiff;h=4d09d37c6aa9a02b44b1fdb6268820fab92499bd fix] of course.)</li>
<li>Reportedly, Windows Server 2012.</li>
</ul>

=== 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 <code>rdesktop</code>.

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 <code>cdboot.efi</code> 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, <code>cdboot.efi</code> 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 <code>/var/lib/libvirt/dnsmasq/default.leases</code> for the guest's MAC address (which is present in its libvirt XML file).

An example <code>AutoUnattend.xml</code> file, and a corresponding guest XML template (to be used with <code>virsh define</code>) 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 <code>AutoUnattend.xml</code> file is named <code>en_windows_server_2008_r2_with_sp1_x64_dvd_617601.iso</code>, its SHA1 is <code>D3FD7BF85EE1D5BDD72DE5B2C69A7B470733CD0A</code>.

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

<pre>
begin-base64 600 example.tar.xz
/Td6WFoAAATm1rRGAgAhARwAAAAQz1jM4E//CfBeABcLxoeSWjrZw/K8YRQW
idsezUdpMAqJW5IviTmcQju7k4hzXixJbgHx/lAbmsS4smaCA12Xj2lLrVcL
E1Z9mz09+Ij1Kt0XX+FZ71T3wbLjFAtmMqv2ZX4v22sO46I2MWFU73vaGh4O
GjeLF6R3VInHrsdMGiZWBcuJBtuLjfCw1fL34okX9kyOayKqAhX6Apf7hTDV
nG9aCmkmSlXL8JXEnbfni0kCGWadOF1U8hKOHlwoO+RHqsjV6UHjj+ODN654
XEvjRvNNBWqx1xwiN+wfseijss/SEsWHBAuDENkfTDNcButwZSjtMGFAGZYa
V8hb+emUu9dc+FG0KcnF6uuEpsf75afmB5PZbVt97SanoylqMGXT6etzXqfE
vvf6XsFC/Xlg3pZ7wgKkZuPNuR7eBcSLatQ9ZLHfndTFlUjcFJT2WyBfZXPV
ahyxItkAjzdi8s0EjfxXqYXgvdWYHqXzZ427QvEo4InkCU6E1TuE7vnMxy7X
1AEIHKU6V+LxEL6X7jTZL/JRFBsmn6A7wTzX58yeo5aiMwKLbvjDuEZEXQFM
3+OXEHPCO/4nQZjyIYNkfnXD8oBKVs+9/wxtQNkvRNw2+guySBPjCX5n3+uR
S2ThSwxwE0y8vRdtggwQK/MfkHL18/IuSJiqSzw0mdoRlwMmpPtgCyI+iryK
rrSsO1qckmHCah6t3FKss86wE0ODbC9WoOVUGxnjE7cjbHg/rh+j4dvFm4Z8
+D6gWK/GXyEI3mbBnp4UqOWEWj6gZmO2QpvHxY9AFaiiSQ+hwUVPk3anufNk
ZIUQdtcsKYNw2V4UdP8CXlU9gWGPw8Y4TvgNXOVNbFbqBA+5gRXj/JNzxyDk
Bkol0zFlRAIcf6yvnmahXkIh6Cu/BnRoJ4IZ1lttvWT8yBTJpkwjjyhHsutM
jSmq8TCHXp2xi7O5bDfYTqSIXVlVs1ltwPQ2++CI5kshoIdq2D09OcrXoq75
Tl+vHDwq6ZhPXWQZ4EPfLztvAKDz2koNOZsMsLOO6TdMSuqJ78f2mliXNeVo
ENEpkYMa6+8XDBx3cv4uXYYhI+WY4ceObv/Og3SV+x4R+cEd4ULVJkRh36U9
NC3BL6krhuIBTR+9SFktjue/5/f0vkPDtstIFTwfByRkHWeGVvIVW0u8dIVW
Fi8Xd0PzLMeym8Oxff4dqbuxK3+CrB/75Pv5ZylACCuzyS5YUxuosPvMf9ME
nCk9Mw+VNyMocjkY7oujQUHwOK481GvX0Yuitc/7kjbyGGsbuAuE+Zi0zsPX
7XirMMRO73TorzyofaFJT6CyeHak6vyP3meDjulDphSgiCvWCSRgP4GYcHgY
uNjZXFOr1mDNLz3qgowmrPrTsLDvi+ByX6jo8RuP/S3P76yJj93bHDVuKcwS
W8CMtDRBc265yAIZARrq/mO53AeZyMlBqDJ/bp/8TTboKTG8IdbHSdVetcWx
WqVNCAb8qgvuN9z4ziarfAbpkNnuQ37hyiFsE4DKJVUXVac/E9vPXP7jcX/S
xhjVULDlMxFl76n8b6pVqW0AnZkpnEujgojQaS0/9Z+h9fQjBwzDlBpgLHeO
Loxh93Jm+aEYpa2Vk5xvQkwkwA8g5mGBm38+lb1BeGP33ygTf9j34SDa/BQa
iJKKEbtH4jW8Dg0bzmtdUNjhRbUYRTyGfseVig8aE5CHfPxkMSeSqGXV7cZh
qIzgrHPi+5kL23NfekhmZRC2IcfWgjoGuGtJYKWQ0u/VLIB1qiRjqauRxt/3
0VUapTQzcLT9JwCZXYyuQu5fMYGoOGvPg3Tjs0N5viZkRyowWSlJoTsof0hd
wajrKWJTXfvdl4AdsTBbaWFkfgZMSg5C7xoFhEa86B+0NO61CAFUvXYiP6PP
tjTNFvSFNvLnWyydFFaMIwET4UHo0gSYmsE9jtzcPxZ2EPkHEVdpVINMM/5Z
SBeDwPGczcXVD/kekhe7YlnUs6GKsdCP9fTcuEQzOat8agFazZkgeT44Ybwi
4xWFD4dlSkeWOAJOfJbU3BDo639qt38+x6/GX3Ad4j/911w0vMlEtMhk/Wg3
ppIfxwlUQ6oB5bB03rOUUJQf4xFwh4eT2JzL33Cve18FjCO2eRAXylTxC1j1
Uh539CcXjlYj908fUl7fkiTMg4V9XW39c8zRpHUXJWWUkCXf5wqRJoQ7sWZ6
kGlr6wmui7kEGP0wumPzn0yJeHx9JWjvLy2SPFp4znCgxISlPksgweyyeejc
FoZzqVmAwvF47bytD8OQ+8FWEpPVFO6S1VLjq/LlNukrfwODWEv+JzazWpy/
CXBmgebmWCFG+Gtdidmc4LMljonAaOdoj0+aXlTVjWzlGZcTDcXQNvDfdsza
2XhRxQyB/yST5auqElN5M+E4sco7AgRFC7em8H3NVfFn12z1mjZBVkWuT/e1
X4QURf4rw3LSZ5HssJdpE7gMR4yPd5tEkVB4a193LVi0o001icPUrwNHBjge
WJd1ecDQwXmtyRlyF/0sPgIdU8g3LaZiEp13M+gGK+3oXcWwpFouav9DzUQr
WPhB7yNGaSK/YH+dPwdif5C9EtyWYcue73YCGtxXgYCUvALKoSxFyeCNnbWH
VY9VFrtC84a4npJ29LurGCXQEMUfDyGqEayJa4iL3u3i7VA1+NgHdtMFZN5o
rL4/d+NZYUsPzqYN2RfOOBLMv4E7lkOIPiMIShD5/cyUEoc2nRT7dr6F1dib
ZjFua4YDUTOWF/4Tt3qg67wTWKsKUObciAKLrreL9u/lxpEHarAXZMiz2oHw
7vZJYLRWyuoJcIm3v4tptkIYk66iMY1oXfM+AmYMtg71XLFyOIiqR0HLj7m3
UW3ANa7RaJG0xaabvpcx5syoeudWOKy1geJurk645d6JTB9pvb71Kcy7kvlx
bwTgR3ITDGb+A9ZByqofoEojQN7fBk0LI0ucHiNGyHDBCXHPOIhHypWRJvyA
bmhY0YIY6ul9RaBhPJnJ2MzVY58NS9s39yolC7cq/ONYh43yyyiECg41wD4K
fN+c0PQ1HXhgm1JMxAYK02GJP5sOHfaW2e/9U54Y+Cnn2Nw33Fbk5a85Vmrq
A0g6s2tJpo1uiawxK4cQKbV4YO8O9+Km0ICk1YkpBWd4szLBeFjk/73Bu618
rAWez/0z41lEaJpEbqDr3ww4YSZiI6BSOwuEbvEuhAkXjA9WvnFQZsys6CFR
mYYT0RT/kvaMvCvH7gJSgjRKnvheUiXB1jd+nlYQ8Ag4qk/8SAfee1r8mZee
NBH0Lr0llRnfnIXBQskmSaBAoQDubDsR1wzgVZKvnCEzFow2colupVMcAdx6
djzC/XgCOPqyX6RtHNrZ/DvTjNhQtGEp9TFLmdoYgvPOqizHGRm28yr5Te07
rr2OzQuw7nLDAACI8Ak60A6nlgABjBSAoAEAJut9ErHEZ/sCAAAAAARZWg==
====
</pre>

=== Confirmation of secure boot in Fedora 18 ===

(This is a write-up of an earlier test.)

<ol>
<li>I rebuilt OVMF with secure boot support.</li>

<li>I downloaded the x86_64 binary RPM for [http://koji.fedoraproject.org/koji/buildinfo?buildID=357608 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>:

<pre>
certutil -L -d f18-keys -n 'Red Hat Test Certificate' -r \
>RedHatTestCertificate.der

certutil -L -d f18-keys -n 'Red Hat Test CA' -r \
>RedHatTestCA.der
</pre>
</li>

<li>I created a 64MB zero file,</li>

<ul>
<li>set up /dev/loop1 on it,</li>
<li>created an MBR partition table with one 0x0c partition (cfdisk),</li>
<li>(maybe ran kpartx -a /dev/loop1,)</li>
<li>formatted /dev/mapper/loop1p1 as FAT32 with mkdosfs,</li>
<li>mounted it, created a directory called "Red Hat Secure Boot Keys",</li>
<li>copied the output files from the previous step there.</li>
<li>NOTE: libguestfs / guestfish is a much better way to do the same.
</li>
</ul>

<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>

<ul>
<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>
</ul>

<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

<pre>
[ 0.000000] Secure boot enabled
</pre>
</li>

<li>
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).
</li>
</ol>

=== Confirmation of secure boot in Windows 2008 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:

<ul>
<li>I downloaded the platform key, the key exchange key, and three DB entries from [http://blog.hansenpartnership.com/the-microsoft-keys/ James Bottomley's blog].</li>
<li>Once inside the guest, I [http://msdn.microsoft.com/en-us/library/windows/desktop/hh847889.aspx started PowerShell as an administrator] and
then [http://communities.intel.com/community/vproexpert/blog/2012/06/26/microsoft-windows-8--enabling-secure-boot verified that Secure Boot was enabled].</li>
</ul>