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