]> git.proxmox.com Git - mirror_edk2.git/blobdiff - OvmfPkg/README
UefiCpuPkg: Move AsmRelocateApLoopStart from Mpfuncs.nasm to AmdSev.nasm
[mirror_edk2.git] / OvmfPkg / README
index 304e69fbe5456d57ae1e0d4bf95800b3a91b3793..0a408abf019d311d5eebfe03aa7627ccfb03b394 100644 (file)
@@ -11,10 +11,10 @@ http://www.tianocore.org/ovmf/
 \r
 Current capabilities:\r
 * IA32 and X64 architectures\r
 \r
 Current capabilities:\r
 * IA32 and X64 architectures\r
-* QEMU (0.10.0 or later)\r
+* QEMU (version 1.7.1 or later, with 1.7 or later machine types)\r
   - Video, keyboard, IDE, CD-ROM, serial\r
   - Runs UEFI shell\r
   - Video, keyboard, IDE, CD-ROM, serial\r
   - Runs UEFI shell\r
-  - Optional NIC support.  Requires QEMU (0.12.2 or later)\r
+  - Optional NIC support.\r
 * UEFI Linux boots\r
 * UEFI Windows 8 boots\r
 * UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)\r
 * UEFI Linux boots\r
 * UEFI Windows 8 boots\r
 * UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)\r
@@ -53,17 +53,19 @@ these binary outputs:
 * OvmfVideo.rom\r
   - This file is not built separately any longer, starting with svn r13520.\r
 \r
 * OvmfVideo.rom\r
   - This file is not built separately any longer, starting with svn r13520.\r
 \r
-More information on building OVMF can be found at:\r
+If you are new to building in edk2 or looking for the latest build\r
+instructions, visit https://github.com/tianocore/tianocore.github.io/wiki/Build-Instructions\r
+\r
+More OVMF-specific build information can be found at:\r
 \r
 https://github.com/tianocore/tianocore.github.io/wiki/How%20to%20build%20OVMF\r
 \r
 === RUNNING OVMF on QEMU ===\r
 \r
 \r
 https://github.com/tianocore/tianocore.github.io/wiki/How%20to%20build%20OVMF\r
 \r
 === RUNNING OVMF on QEMU ===\r
 \r
-* QEMU 0.12.2 or later is required.\r
-* Be sure to use qemu-system-x86_64, if you are using and X64 firmware.\r
+* Be sure to use qemu-system-x86_64, if you are using an X64 firmware.\r
   (qemu-system-x86_64 works for the IA32 firmware as well, of course.)\r
 * Use OVMF for QEMU firmware (3 options available)\r
   (qemu-system-x86_64 works for the IA32 firmware as well, of course.)\r
 * Use OVMF for QEMU firmware (3 options available)\r
-  - Option 1: QEMU 1.6 or newer; Use QEMU -pflash parameter\r
+  - Option 1: Use QEMU -pflash parameter\r
     * QEMU/OVMF will use emulated flash, and fully support UEFI variables\r
     * Run qemu with: -pflash path/to/OVMF.fd\r
     * Note that this option is required for running SecureBoot-enabled builds\r
     * QEMU/OVMF will use emulated flash, and fully support UEFI variables\r
     * Run qemu with: -pflash path/to/OVMF.fd\r
     * Note that this option is required for running SecureBoot-enabled builds\r
@@ -115,8 +117,8 @@ $ OvmfPkg/build.sh -a X64 qemu
 And to run a 64-bit UEFI bootable ISO image:\r
 $ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso\r
 \r
 And to run a 64-bit UEFI bootable ISO image:\r
 $ OvmfPkg/build.sh -a X64 qemu -cdrom /path/to/disk-image.iso\r
 \r
-To build a 32-bit OVMF without debug messages using GCC 4.5:\r
-$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC45\r
+To build a 32-bit OVMF without debug messages using GCC 4.8:\r
+$ OvmfPkg/build.sh -a IA32 -b RELEASE -t GCC48\r
 \r
 === SMM support ===\r
 \r
 \r
 === SMM support ===\r
 \r
@@ -184,76 +186,165 @@ DISCOVER message at startup, the boot process may take approx. 3 seconds
 longer.)\r
 \r
 * For each NIC emulated by qemu, a GPLv2 licensed UEFI driver is available from\r
 longer.)\r
 \r
 * For each NIC emulated by qemu, a GPLv2 licensed UEFI driver is available from\r
-  the iPXE project. The qemu source distribution, starting with version 1.5,\r
-  contains prebuilt binaries of these drivers (and of course allows one to\r
-  rebuild them from source as well). This is the recommended set of drivers.\r
+  the iPXE project. The qemu source distribution contains prebuilt binaries of\r
+  these drivers (and of course allows one to rebuild them from source as well).\r
+  This is the recommended set of drivers.\r
 \r
 * Use the qemu -netdev and -device options, or the legacy -net option, to\r
   enable NIC support: <http://wiki.qemu.org/Documentation/Networking>.\r
 \r
 \r
 * Use the qemu -netdev and -device options, or the legacy -net option, to\r
   enable NIC support: <http://wiki.qemu.org/Documentation/Networking>.\r
 \r
-* For a qemu >= 1.5 binary running *without* any "-M machine" option where\r
-  "machine" would identify a < qemu-1.5 configuration (for example: "-M\r
-  pc-i440fx-1.4" or "-M pc-0.13"), the iPXE drivers are automatically available\r
-  to and configured for OVMF in the default qemu installation.\r
-\r
-* For a qemu binary in [0.13, 1.5), or a qemu >= 1.5 binary with an "-M\r
-  machine" option where "machine" selects a < qemu-1.5 configuration:\r
-\r
-  - download a >= 1.5.0-rc1 source tarball from <http://wiki.qemu.org/Download>,\r
-\r
-  - extract the following iPXE driver files from the tarball and install them\r
-    in a location that is accessible to qemu processes (this may depend on your\r
-    SELinux configuration, for example):\r
-\r
-    qemu-VERSION/pc-bios/efi-e1000.rom\r
-    qemu-VERSION/pc-bios/efi-ne2k_pci.rom\r
-    qemu-VERSION/pc-bios/efi-pcnet.rom\r
-    qemu-VERSION/pc-bios/efi-rtl8139.rom\r
-    qemu-VERSION/pc-bios/efi-virtio.rom\r
-\r
-  - extend the NIC's -device option on the qemu command line with a matching\r
-    "romfile=" optarg:\r
-\r
-    -device e1000,...,romfile=/full/path/to/efi-e1000.rom\r
-    -device ne2k_pci,...,romfile=/full/path/to/efi-ne2k_pci.rom\r
-    -device pcnet,...,romfile=/full/path/to/efi-pcnet.rom\r
-    -device rtl8139,...,romfile=/full/path/to/efi-rtl8139.rom\r
-    -device virtio-net-pci,...,romfile=/full/path/to/efi-virtio.rom\r
+* The iPXE drivers are automatically available to and configured for OVMF in\r
+  the default qemu installation.\r
 \r
 * Independently of the iPXE NIC drivers, the default OVMF build provides a\r
   basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.\r
 \r
 * Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC\r
 \r
 * Independently of the iPXE NIC drivers, the default OVMF build provides a\r
   basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.\r
 \r
 * Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC\r
-  driver (PROEFI) can be embedded in the OVMF image at build time:\r
-\r
-  - Download UEFI drivers for the e1000 NIC\r
-    - http://downloadcenter.intel.com/Detail_Desc.aspx?agr=Y&DwnldID=17515&lang=eng\r
-    - Install the drivers into a directory called Intel3.5 in your WORKSPACE.\r
+  driver (from the BootUtil distribution) can be embedded in the OVMF image at\r
+  build time:\r
+\r
+  - Download BootUtil:\r
+    - Navigate to\r
+      https://downloadcenter.intel.com/download/19186/Ethernet-Intel-Ethernet-Connections-Boot-Utility-Preboot-Images-and-EFI-Drivers\r
+    - Click the download link for "PREBOOT.EXE".\r
+    - Accept the Intel Software License Agreement that appears.\r
+    - Unzip "PREBOOT.EXE" into a separate directory (this works with the\r
+      "unzip" utility on platforms different from Windows as well).\r
+    - Copy the "APPS/EFI/EFIx64/E3522X2.EFI" driver binary to\r
+      "Intel3.5/EFIX64/E3522X2.EFI" in your WORKSPACE.\r
+    - Intel have stopped distributing an IA32 driver binary (which used to\r
+      match the filename pattern "E35??E2.EFI"), thus this method will only\r
+      work for the IA32X64 and X64 builds of OVMF.\r
 \r
   - Include the driver in OVMF during the build:\r
 \r
   - Include the driver in OVMF during the build:\r
-    - Add "-D E1000_ENABLE" to your build command,\r
+    - Add "-D E1000_ENABLE" to your build command (only when building\r
+      "OvmfPkg/OvmfPkgIa32X64.dsc" or "OvmfPkg/OvmfPkgX64.dsc").\r
     - For example: "build -D E1000_ENABLE".\r
 \r
 * When a matching iPXE driver is configured for a NIC as described above, it\r
   takes priority over other drivers that could possibly drive the card too:\r
 \r
     - For example: "build -D E1000_ENABLE".\r
 \r
 * When a matching iPXE driver is configured for a NIC as described above, it\r
   takes priority over other drivers that could possibly drive the card too:\r
 \r
-                 | e1000  ne2k_pci  pcnet  rtl8139  virtio-net-pci\r
-    -------------+------------------------------------------------\r
-    iPXE         |   x       x        x       x           x\r
-    VirtioNetDxe |                                        x\r
-    Intel PROEFI |   x\r
+                         | e1000  ne2k_pci  pcnet  rtl8139  virtio-net-pci\r
+    ---------------------+------------------------------------------------\r
+    iPXE                 |   x       x        x       x           x\r
+    VirtioNetDxe         |                                        x\r
+    Intel BootUtil (X64) |   x\r
+\r
+=== HTTPS Boot ===\r
+\r
+HTTPS Boot is an alternative solution to PXE. It replaces the tftp server\r
+with a HTTPS server so the firmware can download the images through a trusted\r
+and encrypted connection.\r
+\r
+* To enable HTTPS Boot, you have to build OVMF with -D NETWORK_HTTP_BOOT_ENABLE\r
+  and -D NETWORK_TLS_ENABLE. The former brings in the HTTP stack from\r
+  NetworkPkg while the latter enables TLS support in both NetworkPkg and\r
+  CryptoPkg.\r
+\r
+  If you want to exclude the unsecured HTTP connection completely, OVMF has to\r
+  be built with -D NETWORK_ALLOW_HTTP_CONNECTIONS=FALSE so that only the HTTPS\r
+  connections will be accepted.\r
+\r
+* By default, there is no trusted certificate. The user has to import the\r
+  certificates either manually with "Tls Auth Configuration" utility in the\r
+  firmware UI or through the fw_cfg entry, etc/edk2/https/cacerts.\r
+\r
+  -fw_cfg name=etc/edk2/https/cacerts,file=<certdb>\r
+\r
+  The blob for etc/edk2/https/cacerts has to be in the format of Signature\r
+  Database(*1). You can use p11-kit(*2) or efisiglit(*3) to create the\r
+  certificate list.\r
+\r
+  If you want to create the certificate list based on the CA certificates\r
+  in your local host, p11-kit will be a good choice. Here is the command to\r
+  create the list:\r
+\r
+  p11-kit extract --format=edk2-cacerts --filter=ca-anchors \\r
+    --overwrite --purpose=server-auth <certdb>\r
+\r
+  If you only want to import one certificate, efisiglist is the tool for you:\r
+\r
+  efisiglist -a <cert file> -o <certdb>\r
+\r
+  Please note that the certificate has to be in the DER format.\r
+\r
+  You can also append a certificate to the existing list with the following\r
+  command:\r
+\r
+  efisiglist -i <old certdb> -a <cert file> -o <new certdb>\r
+\r
+  NOTE: You may need the patch to make efisiglist generate the correct header.\r
+  (https://github.com/rhboot/pesign/pull/40)\r
+\r
+* Besides the trusted certificates, it's also possible to configure the trusted\r
+  cipher suites for HTTPS through another fw_cfg entry: etc/edk2/https/ciphers.\r
+\r
+  OVMF expects a binary UINT16 array which comprises the cipher suites HEX\r
+  IDs(*4). If the cipher suite list is given, OVMF will choose the cipher\r
+  suite from the intersection of the given list and the built-in cipher\r
+  suites. Otherwise, OVMF just chooses whatever proper cipher suites from the\r
+  built-in ones.\r
+\r
+  - Using QEMU 5.2 or later, QEMU can expose the ordered list of permitted TLS\r
+    cipher suites from the host side to OVMF:\r
+\r
+  -object tls-cipher-suites,id=mysuite0,priority=@SYSTEM \\r
+  -fw_cfg name=etc/edk2/https/ciphers,gen_id=mysuite0\r
+\r
+  (Refer to the QEMU manual and to\r
+  <https://gnutls.org/manual/html_node/Priority-Strings.html> for more\r
+  information on the "priority" property.)\r
+\r
+  - Using QEMU 5.1 or earlier, the array has to be passed from a file:\r
+\r
+  -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>\r
+\r
+  whose contents can be generated with the following script, for example:\r
+\r
+  export LC_ALL=C\r
+  openssl ciphers -V \\r
+  | sed -r -n \\r
+     -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \\r
+  | xargs -r -- printf -- '%b' > ciphers.bin\r
+\r
+  This script creates ciphers.bin that contains all the cipher suite IDs\r
+  supported by openssl according to the local host configuration.\r
+\r
+  You may want to enable only a limited set of cipher suites. Then, you\r
+  should check the validity of your list first:\r
+\r
+  openssl ciphers -V <cipher list>\r
+\r
+  If all the cipher suites in your list map to the proper HEX IDs, go ahead\r
+  to modify the script and execute it:\r
+\r
+  export LC_ALL=C\r
+  openssl ciphers -V <cipher list> \\r
+  | sed -r -n \\r
+     -e 's/^ *0x([0-9A-F]{2}),0x([0-9A-F]{2}) - .*$/\\\\x\1 \\\\x\2/p' \\r
+  | xargs -r -- printf -- '%b' > ciphers.bin\r
+\r
+(*1) See "31.4.1 Signature Database" in UEFI specification 2.7 errata A.\r
+(*2) p11-kit: https://github.com/p11-glue/p11-kit/\r
+(*3) efisiglist: https://github.com/rhboot/pesign/blob/master/src/efisiglist.c\r
+(*4) https://wiki.mozilla.org/Security/Server_Side_TLS#Cipher_names_correspondence_table\r
 \r
 === OVMF Flash Layout ===\r
 \r
 \r
 === OVMF Flash Layout ===\r
 \r
-Like all current IA32/X64 system designs, OVMF's firmware\r
-device (rom/flash) appears in QEMU's physical address space\r
-just below 4GB (0x100000000).\r
+Like all current IA32/X64 system designs, OVMF's firmware device (rom/flash)\r
+appears in QEMU's physical address space just below 4GB (0x100000000).\r
+\r
+OVMF supports building a 1MB, 2MB or 4MB flash image (see the DSC files for the\r
+FD_SIZE_1MB, FD_SIZE_2MB, FD_SIZE_4MB build defines). The base address for the\r
+1MB image in QEMU physical memory is 0xfff00000. The base address for the 2MB\r
+image is 0xffe00000. The base address for the 4MB image is 0xffc00000.\r
 \r
 \r
-The layout of the firmware device in memory looks like:\r
+Using the 1MB or 2MB image, the layout of the firmware device in memory looks\r
+like:\r
 \r
 +--------------------------------------- 4GB (0x100000000)\r
 | VTF0 (16-bit reset code) and OVMF SEC\r
 \r
 +--------------------------------------- 4GB (0x100000000)\r
 | VTF0 (16-bit reset code) and OVMF SEC\r
-| (SECFV)\r
+| (SECFV, 208KB/0x34000)\r
 +--------------------------------------- varies based on flash size\r
 |\r
 | Compressed main firmware image\r
 +--------------------------------------- varies based on flash size\r
 |\r
 | Compressed main firmware image\r
@@ -271,34 +362,33 @@ The layout of the firmware device in memory looks like:
 | area (56KB/0xe000)\r
 +--------------------------------------- base address\r
 \r
 | area (56KB/0xe000)\r
 +--------------------------------------- base address\r
 \r
-OVMF supports building a 1MB or a 2MB flash image. The base address for\r
-a 1MB image in QEMU physical memory is 0xfff00000. The base address for\r
-a 2MB image is 0xffe00000.\r
+Using the 4MB image, the layout of the firmware device in memory looks like:\r
+\r
++--------------------------------------- base + 0x400000 (4GB/0x100000000)\r
+| VTF0 (16-bit reset code) and OVMF SEC\r
+| (SECFV, 208KB/0x34000)\r
++--------------------------------------- base + 0x3cc000\r
+|\r
+| Compressed main firmware image\r
+| (FVMAIN_COMPACT, 3360KB/0x348000)\r
+|\r
++--------------------------------------- base + 0x84000\r
+| Fault-tolerant write (FTW)\r
+| Spare blocks (264KB/0x42000)\r
++--------------------------------------- base + 0x42000\r
+| FTW Work block (4KB/0x1000)\r
++--------------------------------------- base + 0x41000\r
+| Event log area (4KB/0x1000)\r
++--------------------------------------- base + 0x40000\r
+| Non-volatile variable storage\r
+| area (256KB/0x40000)\r
++--------------------------------------- base address (0xffc00000)\r
 \r
 The code in SECFV locates FVMAIN_COMPACT, and decompresses the\r
 main firmware (MAINFV) into RAM memory at address 0x800000. The\r
 remaining OVMF firmware then uses this decompressed firmware\r
 volume image.\r
 \r
 \r
 The code in SECFV locates FVMAIN_COMPACT, and decompresses the\r
 main firmware (MAINFV) into RAM memory at address 0x800000. The\r
 remaining OVMF firmware then uses this decompressed firmware\r
 volume image.\r
 \r
-=== UNIXGCC Debug ===\r
-\r
-If you build with the UNIXGCC toolchain, then debugging will be disabled\r
-due to larger image sizes being produced by the UNIXGCC toolchain. The\r
-first choice recommendation is to use GCC44 or newer instead.\r
-\r
-If you must use UNIXGCC, then you can override the build options for\r
-particular libraries and modules in the .dsc to re-enable debugging\r
-selectively. For example:\r
-  [Components]\r
-  OvmfPkg/Library/PlatformBootManagerLib/PlatformBootManagerLib.inf {\r
-    <BuildOptions>\r
-      GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG\r
-  }\r
-  MdeModulePkg/Universal/BdsDxe/BdsDxe.inf {\r
-    <BuildOptions>\r
-      GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG\r
-  }\r
-\r
 === UEFI Windows 7 & Windows 2008 Server ===\r
 \r
 * One of the '-vga std' and '-vga qxl' QEMU options should be used.\r
 === UEFI Windows 7 & Windows 2008 Server ===\r
 \r
 * One of the '-vga std' and '-vga qxl' QEMU options should be used.\r