README 18 KB

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