to support firmware for Virtual Machines using the edk2\r
code base. More information can be found at:\r
\r
-http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF\r
+http://www.tianocore.org/ovmf/\r
\r
=== STATUS ===\r
\r
-Current status: Alpha\r
-\r
Current capabilities:\r
* IA32 and X64 architectures\r
* QEMU (0.10.0 or later)\r
- Optional NIC support. Requires QEMU (0.12.2 or later)\r
* UEFI Linux boots\r
* UEFI Windows 8 boots\r
+* UEFI Windows 7 & Windows 2008 Server boot (see important notes below!)\r
\r
=== FUTURE PLANS ===\r
\r
-* Stabilize UEFI Linux boot\r
* Test/Stabilize UEFI Self-Certification Tests (SCT) results\r
\r
=== BUILDING OVMF ===\r
* A properly configured ASL compiler:\r
- Intel ASL compiler: Available from http://www.acpica.org\r
- Microsoft ASL compiler: Available from http://www.acpi.info\r
+* NASM: http://www.nasm.us/\r
\r
Update Conf/target.txt ACTIVE_PLATFORM for OVMF:\r
PEI arch DXE arch UEFI interfaces\r
\r
More information on building OVMF can be found at:\r
\r
-http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF\r
+https://github.com/tianocore/tianocore.github.io/wiki/How%20to%20build%20OVMF\r
\r
=== RUNNING OVMF on QEMU ===\r
\r
-* QEMU 0.9.1 or later is required.\r
-* Either copy, rename or symlink OVMF.FD => bios.bin\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
(qemu-system-x86_64 works for the IA32 firmware as well, of course.)\r
-* Use the QEMU -L parameter to specify the directory where the bios.bin\r
- file is located.\r
+* Use OVMF for QEMU firmware (3 options available)\r
+ - Option 1: QEMU 1.6 or newer; 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
+ (-D SECURE_BOOT_ENABLE).\r
+ - Option 2: Use QEMU -bios parameter\r
+ * Note that UEFI variables will be partially emulated, and non-volatile\r
+ variables may lose their contents after a reboot\r
+ * Run qemu with: -bios path/to/OVMF.fd\r
+ - Option 3: Use QEMU -L parameter\r
+ * Note that UEFI variables will be partially emulated, and non-volatile\r
+ variables may lose their contents after a reboot\r
+ * Either copy, rename or symlink OVMF.fd => bios.bin\r
+ * Use the QEMU -L parameter to specify the directory where the bios.bin\r
+ file is located.\r
* The EFI shell is built into OVMF builds at this time, so it should\r
run automatically if a UEFI boot application is not found on the\r
removable media.\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
+Requirements:\r
+* SMM support requires QEMU 2.5.\r
+* The minimum required QEMU machine type is "pc-q35-2.5".\r
+* SMM with KVM requires Linux 4.4 (host).\r
+\r
+OVMF is capable of utilizing SMM if the underlying QEMU or KVM hypervisor\r
+emulates SMM. SMM is put to use in the S3 suspend and resume infrastructure,\r
+and in the UEFI variable driver stack. The purpose is (virtual) hardware\r
+separation between the runtime guest OS and the firmware (OVMF), with the\r
+intent to make Secure Boot actually secure, by preventing the runtime guest OS\r
+from tampering with the variable store and S3 areas.\r
+\r
+For SMM support, OVMF must be built with the "-D SMM_REQUIRE" option. The\r
+resultant firmware binary will check if QEMU actually provides SMM emulation;\r
+if it doesn't, then OVMF will log an error and trigger an assertion failure\r
+during boot (even in RELEASE builds). Both the naming of the flag (SMM_REQUIRE,\r
+instead of SMM_ENABLE), and this behavior are consistent with the goal\r
+described above: this is supposed to be a security feature, and fallbacks are\r
+not allowed. Similarly, a pflash-backed variable store is a requirement.\r
+\r
+QEMU should be started with the options listed below (in addition to any other\r
+guest-specific flags). The command line should be gradually composed from the\r
+hints below. '\' is used to extend the command line to multiple lines, and '^'\r
+can be used on Windows.\r
+\r
+* QEMU binary and options specific to 32-bit guests:\r
+\r
+ $ qemu-system-i386 -cpu coreduo,-nx \\r
+\r
+ or\r
+\r
+ $ qemu-system-x86_64 -cpu <MODEL>,-lm,-nx \\r
+\r
+* QEMU binary for running 64-bit guests (no particular options):\r
+\r
+ $ qemu-system-x86_64 \\r
+\r
+* Flags common to all SMM scenarios (only the Q35 machine type is supported):\r
+\r
+ -machine q35,smm=on,accel=(tcg|kvm) \\r
+ -m ... \\r
+ -smp ... \\r
+ -global driver=cfi.pflash01,property=secure,value=on \\r
+ -drive if=pflash,format=raw,unit=0,file=OVMF_CODE.fd,readonly=on \\r
+ -drive if=pflash,format=raw,unit=1,file=copy_of_OVMF_VARS.fd \\r
+\r
+* In order to disable S3, add:\r
+\r
+ -global ICH9-LPC.disable_s3=1 \\r
\r
=== Network Support ===\r
\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
- - Add "-D E1000_ENABLE -D FD_SIZE_2MB" to your build command,\r
- - For example: "build -D E1000_ENABLE -D FD_SIZE_2MB".\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
- | e1000 ne2k_pci pcnet rtl8139 virtio-net-pci\r
- -------------+------------------------------------------------\r
- iPXE | x x x x x\r
- VirtioNetDxe | x\r
- Intel PROEFI | x\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/PlatformBdsLib/PlatformBdsLib.inf {\r
- <BuildOptions>\r
- GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG\r
- }\r
- IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {\r
- <BuildOptions>\r
- GCC:*_*_*_CC_FLAGS = -UMDEPKG_NDEBUG\r
- }\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
+ -fw_cfg name=etc/edk2/https/ciphers,file=<cipher suites>\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
+ While the tool(*5) to create the cipher suite array is still under\r
+ development, the array can be generated with the following script:\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
+* In the future (after release 2.12), QEMU should populate both above fw_cfg\r
+ files automatically from the local host configuration, and enable the user\r
+ to override either with dedicated options or properties.\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
+(*5) update-crypto-policies: https://gitlab.com/redhat-crypto/fedora-crypto-policies\r
+\r
+=== OVMF Flash Layout ===\r
+\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
+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
+| (SECFV, 208KB/0x34000)\r
++--------------------------------------- varies based on flash size\r
+|\r
+| Compressed main firmware image\r
+| (FVMAIN_COMPACT)\r
+|\r
++--------------------------------------- base + 0x20000\r
+| Fault-tolerant write (FTW)\r
+| Spare blocks (64KB/0x10000)\r
++--------------------------------------- base + 0x10000\r
+| FTW Work block (4KB/0x1000)\r
++--------------------------------------- base + 0x0f000\r
+| Event log area (4KB/0x1000)\r
++--------------------------------------- base + 0x0e000\r
+| Non-volatile variable storage\r
+| area (56KB/0xe000)\r
++--------------------------------------- base address\r
+\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
+=== UEFI Windows 7 & Windows 2008 Server ===\r
+\r
+* One of the '-vga std' and '-vga qxl' QEMU options should be used.\r
+* Only one video mode, 1024x768x32, is supported at OS runtime.\r
+* The '-vga qxl' QEMU option is recommended. After booting the installed\r
+ guest OS, select the video card in Device Manager, and upgrade its driver\r
+ to the QXL XDDM one. Download location:\r
+ <http://www.spice-space.org/download.html>, Guest | Windows binaries.\r
+ This enables further resolutions at OS runtime, and provides S3\r
+ (suspend/resume) capability.\r