1
2=== OVMF OVERVIEW ===
3
4The Open Virtual Machine Firmware (OVMF) project aims
5to support firmware for Virtual Machines using the edk2
6code base. More information can be found at:
7
8http://www.tianocore.org/ovmf/
9
10=== STATUS ===
11
12Current capabilities:
13* IA32 and X64 architectures
14* QEMU (0.10.0 or later)
15 - Video, keyboard, IDE, CD-ROM, serial
16 - Runs UEFI shell
17 - Optional NIC support. Requires QEMU (0.12.2 or later)
18* UEFI Linux boots
19* UEFI Windows 8 boots
20* UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)
21
22=== FUTURE PLANS ===
23
24* Test/Stabilize UEFI Self-Certification Tests (SCT) results
25
26=== BUILDING OVMF ===
27
28Pre-requisites:
29* Build environment capable of build the edk2 MdeModulePkg.
30* A properly configured ASL compiler:
31 - Intel ASL compiler: Available from http://www.acpica.org
32 - Microsoft ASL compiler: Available from http://www.acpi.info
33* NASM: http://www.nasm.us/
34
35Update Conf/target.txt ACTIVE_PLATFORM for OVMF:
36 PEI arch DXE arch UEFI interfaces
37* OvmfPkg/OvmfPkgIa32.dsc IA32 IA32 IA32
38* OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64 X64
39* OvmfPkg/OvmfPkgX64.dsc X64 X64 X64
40
41Update Conf/target.txt TARGET_ARCH based on the .dsc file:
42 TARGET_ARCH
43* OvmfPkg/OvmfPkgIa32.dsc IA32
44* OvmfPkg/OvmfPkgIa32X64.dsc IA32 X64
45* OvmfPkg/OvmfPkgX64.dsc X64
46
47Following the edk2 build process, you will find the OVMF binaries
48under the $WORKSPACE/Build/*/*/FV directory. The actual path will
49depend on how your build is configured. You can expect to find
50these binary outputs:
51* OVMF.FD
52 - Please note! This filename has changed. Older releases used OVMF.Fv.
53* OvmfVideo.rom
54 - This file is not built separately any longer, starting with svn r13520.
55
56More information on building OVMF can be found at:
57
58https://github.com/tianocore/tianocore.github.io/wiki/How%20to%20build%20OVMF
59
60=== RUNNING OVMF on QEMU ===
61
62* QEMU 0.12.2 or later is required.
63* Be sure to use qemu-system-x86_64, if you are using and X64 firmware.
64 (qemu-system-x86_64 works for the IA32 firmware as well, of course.)
65* Use OVMF for QEMU firmware (3 options available)
66 - Option 1: QEMU 1.6 or newer; Use QEMU -pflash parameter
67 * QEMU/OVMF will use emulated flash, and fully support UEFI variables
68 * Run qemu with: -pflash path/to/OVMF.fd
69 * Note that this option is required for running SecureBoot-enabled builds
70 (-D SECURE_BOOT_ENABLE).
71 - Option 2: Use QEMU -bios parameter
72 * Note that UEFI variables will be partially emulated, and non-volatile
73 variables may lose their contents after a reboot
74 * Run qemu with: -bios path/to/OVMF.fd
75 - Option 3: Use QEMU -L parameter
76 * Note that UEFI variables will be partially emulated, and non-volatile
77 variables may lose their contents after a reboot
78 * Either copy, rename or symlink OVMF.fd => bios.bin
79 * Use the QEMU -L parameter to specify the directory where the bios.bin
80 file is located.
81* The EFI shell is built into OVMF builds at this time, so it should
82 run automatically if a UEFI boot application is not found on the
83 removable media.
84* On Linux, newer version of QEMU may enable KVM feature, and this might
85 cause OVMF to fail to boot. The QEMU '-no-kvm' may allow OVMF to boot.
86* Capturing OVMF debug messages on qemu:
87 - The default OVMF build writes debug messages to IO port 0x402. The
88 following qemu command line options save them in the file called
89 debug.log: '-debugcon file:debug.log -global isa-debugcon.iobase=0x402'.
90 - It is possible to revert to the original behavior, when debug messages were
91 written to the emulated serial port (potentially intermixing OVMF debug
92 output with UEFI serial console output). For this the
93 '-D DEBUG_ON_SERIAL_PORT' option has to be passed to the build command (see
94 the next section), and in order to capture the serial output qemu needs to
95 be started with eg. '-serial file:serial.log'.
96 - Debug messages fall into several categories. Logged vs. suppressed
97 categories are controlled at OVMF build time by the
98 'gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel' bitmask (an UINT32
99 value) in the selected .dsc file. Individual bits of this bitmask are
100 defined in <MdePkg/Include/Library/DebugLib.h>. One non-default bit (with
101 some performance impact) that is frequently set for debugging is 0x00400000
102 (DEBUG_VERBOSE).
103 - The RELEASE build target ('-b RELEASE' build option, see below) disables
104 all debug messages. The default build target is DEBUG.
105
106=== Build Scripts ===
107
108On systems with the bash shell you can use OvmfPkg/build.sh to simplify
109building and running OVMF.
110
111So, for example, to build + run OVMF X64:
112$ OvmfPkg/build.sh -a X64
113$ OvmfPkg/build.sh -a X64 qemu
114
115And to run a 64-bit UEFI bootable ISO image:
116$ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso
117
118To build a 32-bit OVMF without debug messages using GCC 4.8:
119$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC48
120
121=== SMM support ===
122
123Requirements:
124* SMM support requires QEMU 2.5.
125* The minimum required QEMU machine type is "pc-q35-2.5".
126* SMM with KVM requires Linux 4.4 (host).
127
128OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor
129emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure,
130and in the UEFI variable driver stack. The purpose is (virtual) hardware
131separation between the runtime guest OS and the firmware (OVMF), with the
132intent to make Secure Boot actually secure, by preventing the runtime guest OS
133from tampering with the variable store and S3 areas.
134
135For SMM support, OVMF must be built with the "-D SMM_REQUIRE" option. The
136resultant firmware binary will check if QEMU actually provides SMM emulation;
137if it doesn't, then OVMF will log an error and trigger an assertion failure
138during boot (even in RELEASE builds). Both the naming of the flag (SMM_REQUIRE,
139instead of SMM_ENABLE), and this behavior are consistent with the goal
140described above: this is supposed to be a security feature, and fallbacks are
141not allowed. Similarly, a pflash-backed variable store is a requirement.
142
143QEMU should be started with the options listed below (in addition to any other
144guest-specific flags). The command line should be gradually composed from the
145hints below. '\' is used to extend the command line to multiple lines, and '^'
146can be used on Windows.
147
148* QEMU binary and options specific to 32-bit guests:
149
150 $ qemu-system-i386 -cpu coreduo,-nx \
151
152 or
153
154 $ qemu-system-x86_64 -cpu <MODEL>,-lm,-nx \
155
156* QEMU binary for running 64-bit guests (no particular options):
157
158 $ qemu-system-x86_64 \
159
160* Flags common to all SMM scenarios (only the Q35 machine type is supported):
161
162 -machine q35,smm=on,accel=(tcg|kvm) \
163 -m ... \
164 -smp ... \
165 -global driver=cfi.pflash01,property=secure,value=on \
166 -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \
167 -drive if=pflash,format=raw,unit=1,file=copy_of_OVMF_VARS.fd \
168
169* In order to disable S3, add:
170
171 -global ICH9-LPC.disable_s3=1 \
172
173=== Network Support ===
174
175OVMF provides a UEFI network stack by default. Its lowest level driver is the
176NIC driver, higher levels are generic. In order to make DHCP, PXE Boot, and eg.
177socket test utilities from the StdLib edk2 package work, (1) qemu has to be
178configured to emulate a NIC, (2) a matching UEFI NIC driver must be available
179when OVMF boots.
180
181(If a NIC is configured for the virtual machine, and -- dependent on boot order
182-- PXE booting is attempted, but no DHCP server responds to OVMF's DHCP
183DISCOVER message at startup, the boot process may take approx. 3 seconds
184longer.)
185
186* For each NIC emulated by qemu, a GPLv2 licensed UEFI driver is available from
187 the iPXE project. The qemu source distribution, starting with version 1.5,
188 contains prebuilt binaries of these drivers (and of course allows one to
189 rebuild them from source as well). This is the recommended set of drivers.
190
191* Use the qemu -netdev and -device options, or the legacy -net option, to
192 enable NIC support: <http://wiki.qemu.org/Documentation/Networking>.
193
194* For a qemu >= 1.5 binary running *without* any "-M machine" option where
195 "machine" would identify a < qemu-1.5 configuration (for example: "-M
196 pc-i440fx-1.4" or "-M pc-0.13"), the iPXE drivers are automatically available
197 to and configured for OVMF in the default qemu installation.
198
199* For a qemu binary in [0.13, 1.5), or a qemu >= 1.5 binary with an "-M
200 machine" option where "machine" selects a < qemu-1.5 configuration:
201
202 - download a >= 1.5.0-rc1 source tarball from <http://wiki.qemu.org/Download>,
203
204 - extract the following iPXE driver files from the tarball and install them
205 in a location that is accessible to qemu processes (this may depend on your
206 SELinux configuration, for example):
207
208 qemu-VERSION/pc-bios/efi-e1000.rom
209 qemu-VERSION/pc-bios/efi-ne2k_pci.rom
210 qemu-VERSION/pc-bios/efi-pcnet.rom
211 qemu-VERSION/pc-bios/efi-rtl8139.rom
212 qemu-VERSION/pc-bios/efi-virtio.rom
213
214 - extend the NIC's -device option on the qemu command line with a matching
215 "romfile=" optarg:
216
217 -device e1000,...,romfile=/full/path/to/efi-e1000.rom
218 -device ne2k_pci,...,romfile=/full/path/to/efi-ne2k_pci.rom
219 -device pcnet,...,romfile=/full/path/to/efi-pcnet.rom
220 -device rtl8139,...,romfile=/full/path/to/efi-rtl8139.rom
221 -device virtio-net-pci,...,romfile=/full/path/to/efi-virtio.rom
222
223* Independently of the iPXE NIC drivers, the default OVMF build provides a
224 basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.
225
226* Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC
227 driver (from the BootUtil distribution) can be embedded in the OVMF image at
228 build time:
229
230 - Download BootUtil:
231 - Navigate to
232 https://downloadcenter.intel.com/download/19186/Ethernet-Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers
233 - Click the download link for "PREBOOT.EXE".
234 - Accept the Intel Software License Agreement that appears.
235 - Unzip "PREBOOT.EXE" into a separate directory (this works with the
236 "unzip" utility on platforms different from Windows as well).
237 - Copy the "APPS/EFI/EFIx64/E3522X2.EFI" driver binary to
238 "Intel3.5/EFIX64/E3522X2.EFI" in your WORKSPACE.
239 - Intel have stopped distributing an IA32 driver binary (which used to
240 match the filename pattern "E35??E2.EFI"), thus this method will only
241 work for the IA32X64 and X64 builds of OVMF.
242
243 - Include the driver in OVMF during the build:
244 - Add "-D E1000_ENABLE" to your build command (only when building
245 "OvmfPkg/OvmfPkgIa32X64.dsc" or "OvmfPkg/OvmfPkgX64.dsc").
246 - For example: "build -D E1000_ENABLE".
247
248* When a matching iPXE driver is configured for a NIC as described above, it
249 takes priority over other drivers that could possibly drive the card too:
250
251 | e1000 ne2k_pci pcnet rtl8139 virtio-net-pci
252 ---------------------+------------------------------------------------
253 iPXE | x x x x x
254 VirtioNetDxe | x
255 Intel BootUtil (X64) | x
256
257=== HTTPS Boot ===
258
259HTTPS Boot is an alternative solution to PXE. It replaces the tftp server
260with a HTTPS server so the firmware can download the images through a trusted
261and encrypted connection.
262
263* To enable HTTPS Boot, you have to build OVMF with -D HTTP_BOOT_ENABLE and
264 -D TLS_ENABLE. The former brings in the HTTP stack from NetworkPkg while
265 the latter enables TLS support in both NetworkPkg and CryptoPkg.
266
267* By default, there is no trusted certificate. The user has to import the
268 certificates either manually with "Tls Auth Configuration" utility in the
269 firmware UI or through the fw_cfg entry, etc/edk2/https/cacerts.
270
271 -fw_cfg name=etc/edk2/https/cacerts,file=<certdb>
272
273 The blob for etc/edk2/https/cacerts has to be in the format of Signature
274 Database(*1). You can use p11-kit(*2) or efisiglit(*3) to create the
275 certificate list.
276
277 If you want to create the certificate list based on the CA certificates
278 in your local host, p11-kit will be a good choice. Here is the command to
279 create the list:
280
281 p11-kit extract --format=edk2-cacerts --filter=ca-anchors \
282 --overwrite --purpose=server-auth <certdb>
283
284 If you only want to import one certificate, efisiglist is the tool for you:
285
286 efisiglist -a <cert file> -o <certdb>
287
288 Please note that the certificate has to be in the DER format.
289
290 You can also append a certificate to the existing list with the following
291 command:
292
293 efisiglist -i <old certdb> -a <cert file> -o <new certdb>
294
295 NOTE: You may need the patch to make efisiglist generate the correct header.
296 (https://github.com/rhboot/pesign/pull/40)
297
298* Besides the trusted certificates, it's also possible to configure the trusted
299 cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
300
301 -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
302
303 OVMF expects a binary UINT16 array which comprises the cipher suites HEX
304 IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
305 suite from the intersection of the given list and the built-in cipher
306 suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
307 built-in ones.
308
309 While the tool(*5) to create the cipher suite array is still under
310 development, the array can be generated with the following script:
311
312 export LC_ALL=C
313 openssl ciphers -V \
314 | sed -r -n \
315 -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
316 | xargs -r -- printf -- '%b' > ciphers.bin
317
318 This script creates ciphers.bin that contains all the cipher suite IDs
319 supported by openssl according to the local host configuration.
320
321 You may want to enable only a limited set of cipher suites. Then, you
322 should check the validity of your list first:
323
324 openssl ciphers -V <cipher list>
325
326 If all the cipher suites in your list map to the proper HEX IDs, go ahead
327 to modify the script and execute it:
328
329 export LC_ALL=C
330 openssl ciphers -V <cipher list> \
331 | sed -r -n \
332 -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
333 | xargs -r -- printf -- '%b' > ciphers.bin
334
335* In the future (after release 2.12), QEMU should populate both above fw_cfg
336 files automatically from the local host configuration, and enable the user
337 to override either with dedicated options or properties.
338
339(*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
340(*2) p11-kit: https://github.com/p11-glue/p11-kit/
341(*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
342(*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
343(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
344
345=== OVMF Flash Layout ===
346
347Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
348appears in QEMU's physical address space just below 4GB (0x100000000).
349
350OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
351FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
3521MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
353image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
354
355Using the 1MB or 2MB image, the layout of the firmware device in memory looks
356like:
357
358+--------------------------------------- 4GB (0x100000000)
359| VTF0 (16-bit reset code) and OVMF SEC
360| (SECFV, 208KB/0x34000)
361+--------------------------------------- varies based on flash size
362|
363| Compressed main firmware image
364| (FVMAIN_COMPACT)
365|
366+--------------------------------------- base + 0x20000
367| Fault-tolerant write (FTW)
368| Spare blocks (64KB/0x10000)
369+--------------------------------------- base + 0x10000
370| FTW Work block (4KB/0x1000)
371+--------------------------------------- base + 0x0f000
372| Event log area (4KB/0x1000)
373+--------------------------------------- base + 0x0e000
374| Non-volatile variable storage
375| area (56KB/0xe000)
376+--------------------------------------- base address
377
378Using the 4MB image, the layout of the firmware device in memory looks like:
379
380+--------------------------------------- base + 0x400000 (4GB/0x100000000)
381| VTF0 (16-bit reset code) and OVMF SEC
382| (SECFV, 208KB/0x34000)
383+--------------------------------------- base + 0x3cc000
384|
385| Compressed main firmware image
386| (FVMAIN_COMPACT, 3360KB/0x348000)
387|
388+--------------------------------------- base + 0x84000
389| Fault-tolerant write (FTW)
390| Spare blocks (264KB/0x42000)
391+--------------------------------------- base + 0x42000
392| FTW Work block (4KB/0x1000)
393+--------------------------------------- base + 0x41000
394| Event log area (4KB/0x1000)
395+--------------------------------------- base + 0x40000
396| Non-volatile variable storage
397| area (256KB/0x40000)
398+--------------------------------------- base address (0xffc00000)
399
400The code in SECFV locates FVMAIN_COMPACT, and decompresses the
401main firmware (MAINFV) into RAM memory at address 0x800000. The
402remaining OVMF firmware then uses this decompressed firmware
403volume image.
404
405=== UEFI Windows 7 & Windows 2008 Server ===
406
407* One of the '-vga std' and '-vga qxl' QEMU options should be used.
408* Only one video mode, 1024x768x32, is supported at OS runtime.
409* The '-vga qxl' QEMU option is recommended. After booting the installed
410 guest OS, select the video card in Device Manager, and upgrade its driver
411 to the QXL XDDM one. Download location:
412 <http://www.spice-space.org/download.html>, Guest | Windows binaries.
413 This enables further resolutions at OS runtime, and provides S3
414 (suspend/resume) capability.
415