OvmfPkg/README

   1
   2 === OVMF OVERVIEW ===
   3
   4 The Open Virtual Machine Firmware (OVMF) project aims
   5 to support firmware for Virtual Machines using the edk2
   6 code base.  More information can be found at:
   7
   8 http://www.tianocore.org/ovmf/
   9
  10 === STATUS ===
  11
  12 Current 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
  28 Pre-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
  35 Update 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
  41 Update 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
  47 Following the edk2 build process, you will find the OVMF binaries
  48 under the $WORKSPACE/Build/*/*/FV directory.  The actual path will
  49 depend on how your build is configured.  You can expect to find
  50 these 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
  56 More information on building OVMF can be found at:
  57
  58 https://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
 108 On systems with the bash shell you can use OvmfPkg/build.sh to simplify
 109 building and running OVMF.
 110
 111 So, for example, to build + run OVMF X64:
 112 $ OvmfPkg/build.sh -a X64
 113 $ OvmfPkg/build.sh -a X64 qemu
 114
 115 And to run a 64-bit UEFI bootable ISO image:
 116 $ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso
 117
 118 To 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
 123 Requirements:
 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
 128 OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor
 129 emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure,
 130 and in the UEFI variable driver stack. The purpose is (virtual) hardware
 131 separation between the runtime guest OS and the firmware (OVMF), with the
 132 intent to make Secure Boot actually secure, by preventing the runtime guest OS
 133 from tampering with the variable store and S3 areas.
 134
 135 For SMM support, OVMF must be built with the "-D SMM_REQUIRE" option. The
 136 resultant firmware binary will check if QEMU actually provides SMM emulation;
 137 if it doesn't, then OVMF will log an error and trigger an assertion failure
 138 during boot (even in RELEASE builds). Both the naming of the flag (SMM_REQUIRE,
 139 instead of SMM_ENABLE), and this behavior are consistent with the goal
 140 described above: this is supposed to be a security feature, and fallbacks are
 141 not allowed. Similarly, a pflash-backed variable store is a requirement.
 142
 143 QEMU should be started with the options listed below (in addition to any other
 144 guest-specific flags). The command line should be gradually composed from the
 145 hints below. '\' is used to extend the command line to multiple lines, and '^'
 146 can 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
 175 OVMF provides a UEFI network stack by default. Its lowest level driver is the
 176 NIC driver, higher levels are generic. In order to make DHCP, PXE Boot, and eg.
 177 socket test utilities from the StdLib edk2 package work, (1) qemu has to be
 178 configured to emulate a NIC, (2) a matching UEFI NIC driver must be available
 179 when 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
 183 DISCOVER message at startup, the boot process may take approx. 3 seconds
 184 longer.)
 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
 259 HTTPS Boot is an alternative solution to PXE. It replaces the tftp server
 260 with a HTTPS server so the firmware can download the images through a trusted
 261 and encrypted connection.
 262
 263 * To enable HTTPS Boot, you have to build OVMF with -D NETWORK_HTTP_BOOT_ENABLE
 264   and -D NETWORK_TLS_ENABLE. The former brings in the HTTP stack from
 265   NetworkPkg while the latter enables TLS support in both NetworkPkg and
 266   CryptoPkg.
 267
 268   If you want to exclude the unsecured HTTP connection completely, OVMF has to
 269   be built with -D NETWORK_ALLOW_HTTP_CONNECTIONS=FALSE so that only the HTTPS
 270   connections will be accepted.
 271
 272 * By default, there is no trusted certificate. The user has to import the
 273   certificates either manually with "Tls Auth Configuration" utility in the
 274   firmware UI or through the fw_cfg entry, etc/edk2/https/cacerts.
 275
 276   -fw_cfg name=etc/edk2/https/cacerts,file=<certdb>
 277
 278   The blob for etc/edk2/https/cacerts has to be in the format of Signature
 279   Database(*1). You can use p11-kit(*2) or efisiglit(*3) to create the
 280   certificate list.
 281
 282   If you want to create the certificate list based on the CA certificates
 283   in your local host, p11-kit will be a good choice. Here is the command to
 284   create the list:
 285
 286   p11-kit extract --format=edk2-cacerts --filter=ca-anchors \
 287     --overwrite --purpose=server-auth <certdb>
 288
 289   If you only want to import one certificate, efisiglist is the tool for you:
 290
 291   efisiglist -a <cert file> -o <certdb>
 292
 293   Please note that the certificate has to be in the DER format.
 294
 295   You can also append a certificate to the existing list with the following
 296   command:
 297
 298   efisiglist -i <old certdb> -a <cert file> -o <new certdb>
 299
 300   NOTE: You may need the patch to make efisiglist generate the correct header.
 301   (https://github.com/rhboot/pesign/pull/40)
 302
 303 * Besides the trusted certificates, it's also possible to configure the trusted
 304   cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.
 305
 306   -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>
 307
 308   OVMF expects a binary UINT16 array which comprises the cipher suites HEX
 309   IDs(*4). If the cipher suite list is given, OVMF will choose the cipher
 310   suite from the intersection of the given list and the built-in cipher
 311   suites. Otherwise, OVMF just chooses whatever proper cipher suites from the
 312   built-in ones.
 313
 314   While the tool(*5) to create the cipher suite array is still under
 315   development, the array can be generated with the following script:
 316
 317   export LC_ALL=C
 318   openssl ciphers -V \
 319   | sed -r -n \
 320      -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
 321   | xargs -r -- printf -- '%b' > ciphers.bin
 322
 323   This script creates ciphers.bin that contains all the cipher suite IDs
 324   supported by openssl according to the local host configuration.
 325
 326   You may want to enable only a limited set of cipher suites. Then, you
 327   should check the validity of your list first:
 328
 329   openssl ciphers -V <cipher list>
 330
 331   If all the cipher suites in your list map to the proper HEX IDs, go ahead
 332   to modify the script and execute it:
 333
 334   export LC_ALL=C
 335   openssl ciphers -V <cipher list> \
 336   | sed -r -n \
 337      -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \
 338   | xargs -r -- printf -- '%b' > ciphers.bin
 339
 340 * In the future (after release 2.12), QEMU should populate both above fw_cfg
 341   files automatically from the local host configuration, and enable the user
 342   to override either with dedicated options or properties.
 343
 344 (*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.
 345 (*2) p11-kit: https://github.com/p11-glue/p11-kit/
 346 (*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c
 347 (*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table
 348 (*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies
 349
 350 === OVMF Flash Layout ===
 351
 352 Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)
 353 appears in QEMU's physical address space just below 4GB (0x100000000).
 354
 355 OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the
 356 FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the
 357 1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB
 358 image is 0xffe00000. The base address for the 4MB image is 0xffc00000.
 359
 360 Using the 1MB or 2MB image, the layout of the firmware device in memory looks
 361 like:
 362
 363 +--------------------------------------- 4GB (0x100000000)
 364 | VTF0 (16-bit reset code) and OVMF SEC
 365 | (SECFV, 208KB/0x34000)
 366 +--------------------------------------- varies based on flash size
 367 |
 368 | Compressed main firmware image
 369 | (FVMAIN_COMPACT)
 370 |
 371 +--------------------------------------- base + 0x20000
 372 | Fault-tolerant write (FTW)
 373 | Spare blocks (64KB/0x10000)
 374 +--------------------------------------- base + 0x10000
 375 | FTW Work block (4KB/0x1000)
 376 +--------------------------------------- base + 0x0f000
 377 | Event log area (4KB/0x1000)
 378 +--------------------------------------- base + 0x0e000
 379 | Non-volatile variable storage
 380 | area (56KB/0xe000)
 381 +--------------------------------------- base address
 382
 383 Using the 4MB image, the layout of the firmware device in memory looks like:
 384
 385 +--------------------------------------- base + 0x400000 (4GB/0x100000000)
 386 | VTF0 (16-bit reset code) and OVMF SEC
 387 | (SECFV, 208KB/0x34000)
 388 +--------------------------------------- base + 0x3cc000
 389 |
 390 | Compressed main firmware image
 391 | (FVMAIN_COMPACT, 3360KB/0x348000)
 392 |
 393 +--------------------------------------- base + 0x84000
 394 | Fault-tolerant write (FTW)
 395 | Spare blocks (264KB/0x42000)
 396 +--------------------------------------- base + 0x42000
 397 | FTW Work block (4KB/0x1000)
 398 +--------------------------------------- base + 0x41000
 399 | Event log area (4KB/0x1000)
 400 +--------------------------------------- base + 0x40000
 401 | Non-volatile variable storage
 402 | area (256KB/0x40000)
 403 +--------------------------------------- base address (0xffc00000)
 404
 405 The code in SECFV locates FVMAIN_COMPACT, and decompresses the
 406 main firmware (MAINFV) into RAM memory at address 0x800000. The
 407 remaining OVMF firmware then uses this decompressed firmware
 408 volume image.
 409
 410 === UEFI Windows 7 & Windows 2008 Server ===
 411
 412 * One of the '-vga std' and '-vga qxl' QEMU options should be used.
 413 * Only one video mode, 1024x768x32, is supported at OS runtime.
 414 * The '-vga qxl' QEMU option is recommended. After booting the installed
 415   guest OS, select the video card in Device Manager, and upgrade its driver
 416   to the QXL XDDM one. Download location:
 417   <http://www.spice-space.org/download.html>, Guest | Windows binaries.
 418   This enables further resolutions at OS runtime, and provides S3
 419   (suspend/resume) capability.