audk/OvmfPkg
Laszlo Ersek ad43bc6b2e OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3
OVMF's SecMain is unique in the sense that it links against the following
two libraries *in combination*:

- IntelFrameworkModulePkg/Library/LzmaCustomDecompressLib/
                                               LzmaCustomDecompressLib.inf
- MdePkg/Library/BaseExtractGuidedSectionLib/
                                           BaseExtractGuidedSectionLib.inf

The ExtractGuidedSectionLib library class allows decompressor modules to
register themselves (keyed by GUID) with it, and it allows clients to
decompress file sections with a registered decompressor module that
matches the section's GUID.

BaseExtractGuidedSectionLib is a library instance (of type BASE) for this
library class. It has no constructor function.

LzmaCustomDecompressLib is a compatible decompressor module (of type
BASE). Its section type GUID is

  gLzmaCustomDecompressGuid == EE4E5898-3914-4259-9D6E-DC7BD79403CF

When OVMF's SecMain module starts, the LzmaCustomDecompressLib constructor
function is executed, which registers its LZMA decompressor with the above
GUID, by calling into BaseExtractGuidedSectionLib:

  LzmaDecompressLibConstructor() [GuidedSectionExtraction.c]
    ExtractGuidedSectionRegisterHandlers() [BaseExtractGuidedSectionLib.c]
      GetExtractGuidedSectionHandlerInfo()
        PcdGet64 (PcdGuidedExtractHandlerTableAddress) -- NOTE THIS

Later, during a normal (non-S3) boot, SecMain utilizes this decompressor
to get information about, and to decompress, sections of the OVMF firmware
image:

  SecCoreStartupWithStack() [OvmfPkg/Sec/SecMain.c]
    SecStartupPhase2()
      FindAndReportEntryPoints()
        FindPeiCoreImageBase()
          DecompressMemFvs()
            ExtractGuidedSectionGetInfo() [BaseExtractGuidedSectionLib.c]
            ExtractGuidedSectionDecode() [BaseExtractGuidedSectionLib.c]

Notably, only the extraction depends on full-config-boot; the registration
of LzmaCustomDecompressLib occurs unconditionally in the SecMain EFI
binary, triggered by the library constructor function.

This is where the bug happens. BaseExtractGuidedSectionLib maintains the
table of GUIDed decompressors (section handlers) at a fixed memory
location; selected by PcdGuidedExtractHandlerTableAddress (declared in
MdePkg.dec). The default value of this PCD is 0x1000000 (16 MB).

This causes SecMain to corrupt guest OS memory during S3, leading to
random crashes. Compare the following two memory dumps, the first taken
right before suspending, the second taken right after resuming a RHEL-7
guest:

crash> rd -8 -p 1000000 0x50
1000000: c0 00 08 00 02 00 00 00 00 00 00 00 00 00 00 00  ................
1000010: d0 33 0c 00 00 c9 ff ff c0 10 00 01 00 88 ff ff  .3..............
1000020: 0a 6d 57 32 0f 00 00 00 38 00 00 01 00 88 ff ff  .mW2....8.......
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f  ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00  dule.so.........

vs.

crash> rd -8 -p 1000000 0x50
1000000: 45 47 53 49 01 00 00 00 20 00 00 01 00 00 00 00  EGSI.... .......
1000010: 20 01 00 01 00 00 00 00 a0 01 00 01 00 00 00 00   ...............
1000020: 98 58 4e ee 14 39 59 42 9d 6e dc 7b d7 94 03 cf  .XN..9YB.n.{....
1000030: 00 00 00 00 00 00 00 00 73 69 67 6e 61 6c 6d 6f  ........signalmo
1000040: 64 75 6c 65 2e 73 6f 00 00 00 00 00 00 00 00 00  dule.so.........

The "EGSI" signature corresponds to EXTRACT_HANDLER_INFO_SIGNATURE
declared in
MdePkg/Library/BaseExtractGuidedSectionLib/BaseExtractGuidedSectionLib.c.

Additionally, the gLzmaCustomDecompressGuid (quoted above) is visible at
guest-phys offset 0x1000020.

Fix the problem as follows:
- Carve out 4KB from the 36KB gap that we currently have between

  PcdOvmfLockBoxStorageBase + PcdOvmfLockBoxStorageSize == 8220 KB
  and
  PcdOvmfSecPeiTempRamBase                              == 8256 KB.

- Point PcdGuidedExtractHandlerTableAddress to 8220 KB (0x00807000).

- Cover the area with an EfiACPIMemoryNVS type memalloc HOB, if S3 is
  supported and we're not currently resuming.

The 4KB size that we pick is an upper estimate for
BaseExtractGuidedSectionLib's internal storage size. The latter is
calculated as follows (see GetExtractGuidedSectionHandlerInfo()):

  sizeof(EXTRACT_GUIDED_SECTION_HANDLER_INFO) +         // 32
  PcdMaximumGuidedExtractHandler * (
    sizeof(GUID) +                                      // 16
    sizeof(EXTRACT_GUIDED_SECTION_DECODE_HANDLER) +     //  8
    sizeof(EXTRACT_GUIDED_SECTION_GET_INFO_HANDLER)     //  8
    )

OVMF sets PcdMaximumGuidedExtractHandler to 16 decimal (which is the
MdePkg default too), yielding 32 + 16 * (16 + 8 + 8) == 544 bytes.

Regarding the lifecycle of the new area:

(a) when and how it is initialized after first boot of the VM

  The library linked into SecMain finds that the area lacks the signature.
  It initializes the signature, plus the rest of the structure. This is
  independent of S3 support.

  Consumption of the area is also limited to SEC (but consumption does
  depend on full-config-boot).

(b) how it is protected from memory allocations during DXE

  It is not, in the general case; and we don't need to. Nothing else links
  against BaseExtractGuidedSectionLib; it's OK if DXE overwrites the area.

(c) how it is protected from the OS

  When S3 is enabled, we cover it with AcpiNVS in InitializeRamRegions().

  When S3 is not supported, the range is not protected.

(d) how it is accessed on the S3 resume path

  Examined by the library linked into SecMain. Registrations update the
  table in-place (based on GUID matches).

(e) how it is accessed on the warm reset path

  If S3 is enabled, then the OS won't damage the table (due to (c)), hence
  see (d).

  If S3 is unsupported, then the OS may or may not overwrite the
  signature. (It likely will.) This is identical to the pre-patch status.

Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>

git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@15433 6f19259b-4bc3-4df7-8a09-765794883524
2014-04-05 21:26:09 +00:00
..
AcpiPlatformDxe OvmfPkg: AcpiPlatformDxe: download ACPI tables from QEMU 2014-03-31 20:36:06 +00:00
AcpiS3SaveDxe OvmfPkg: AcpiS3SaveDxe: do not load if S3 is unsupported/disabled in qemu 2014-03-31 20:35:58 +00:00
AcpiTables OvmfPkg: report support for the PIIX3 reset register in the FADT 2013-03-04 17:38:05 +00:00
BlockMmioToBlockIoDxe OvmfPkg/BlockMmioToBlockIoDxe: Fix allocation size error 2012-08-28 21:21:44 +00:00
Csm OvmfPkg: Add CSM16 and related drivers if CSM_ENABLE is set 2011-11-10 22:04:49 +00:00
EmuVariableFvbRuntimeDxe OvmfPkg/EmuVariableFvbRuntimeDxe: Disable if flash variables are supported 2013-11-12 18:34:43 +00:00
Include OvmfPkg: introduce gOvmfPlatformConfigGuid 2014-03-22 07:12:46 +00:00
Library OvmfPkg: add a catch-all match for PCI devices in the OpenFirmware path 2014-03-31 20:36:23 +00:00
PlatformDxe OvmfPkg: PlatformDxe: connect RouteConfig() to platform data 2014-03-22 07:14:09 +00:00
PlatformPei OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3 2014-04-05 21:26:09 +00:00
QemuFlashFvbServicesRuntimeDxe OvmfPkg: QemuFlashFvbServicesRuntimeDxe: fix out-of-LBA write access 2013-12-17 18:17:55 +00:00
QemuVideoDxe OvmfPkg: QemuVideoDxe: serialize Start() against callbacks 2014-03-22 07:13:44 +00:00
ResetVector OvmfPkg X64 ResetVector: Move page tables from 512KB to 8MB 2014-01-21 19:38:34 +00:00
Sec OvmfPkg/Sec: Don't decompress the FV on S3 resume 2014-03-04 08:02:37 +00:00
SecureBootConfigDxe OvmfPkg/SecureBootConfigDxe: Avoid illegal access 2013-08-18 07:04:02 +00:00
SmbiosPlatformDxe According to PI errata 0000654 and 000811, we need use 0xFFFE to instead of 0 for EFI_SMBIOS_PROTOCOL.Add() SmbiosHandle parameter to assign a unique handle to the SMBIOS record, and for EFI_SMBIOS_PROTOCOL.GetNext() SmbiosHandle parameter to get the first matched SMBIOS handle or indicate no more SMBIOS record. 2011-11-21 08:57:02 +00:00
VirtioBlkDxe OvmfPkg: VirtioBlkInit(): log topology attributes 2013-12-18 19:57:57 +00:00
VirtioNetDxe OvmfPkg: Virtio drivers: fix incorrect casts in init functions 2013-12-12 17:28:05 +00:00
VirtioPciDeviceDxe OvmfPkg/VirtioPciDeviceDxe: Implement VIRTIO_DEVICE_PROTOCOL for VirtIo Devices over PCI 2013-12-11 16:57:49 +00:00
VirtioScsiDxe OvmfPkg: Virtio drivers: fix incorrect casts in init functions 2013-12-12 17:28:05 +00:00
Contributions.txt EDK II Packages: Add Contributions.txt and License.txt files 2012-04-11 23:19:46 +00:00
License.txt Update copyright format 2012-04-24 06:49:39 +00:00
OvmfPkg.dec OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3 2014-04-05 21:26:09 +00:00
OvmfPkgIa32.dsc OvmfPkg: non-null PcdLib instance for the CSM VideoDxe 2014-03-31 20:36:15 +00:00
OvmfPkgIa32.fdf OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3 2014-04-05 21:26:09 +00:00
OvmfPkgIa32X64.dsc OvmfPkg: non-null PcdLib instance for the CSM VideoDxe 2014-03-31 20:36:15 +00:00
OvmfPkgIa32X64.fdf OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3 2014-04-05 21:26:09 +00:00
OvmfPkgX64.dsc OvmfPkg: non-null PcdLib instance for the CSM VideoDxe 2014-03-31 20:36:15 +00:00
OvmfPkgX64.fdf OvmfPkg: PlatformPei: protect SEC's GUIDed section handler table thru S3 2014-04-05 21:26:09 +00:00
README OvmfPkg/README: Update OVMF status 2014-01-03 19:19:20 +00:00
build.sh OvmfPkg/build.sh: Support GCC48 toolchain 2014-01-20 08:49:58 +00:00
create-release.py OvmfPkg/create-release.py: Read License.txt files 2014-01-03 19:19:43 +00:00

README

This file contains invisible Unicode characters

This file contains invisible Unicode characters that are indistinguishable to humans but may be processed differently by a computer. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.


=== OVMF OVERVIEW ===

The Open Virtual Machine Firmware (OVMF) project aims
to support firmware for Virtual Machines using the edk2
code base.  More information can be found at:

http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=OVMF

=== STATUS ===

Current capabilities:
* IA32 and X64 architectures
* QEMU (0.10.0 or later)
  - Video, keyboard, IDE, CD-ROM, serial
  - Runs UEFI shell
  - Optional NIC support.  Requires QEMU (0.12.2 or later)
* UEFI Linux boots
* UEFI Windows 8 boots

=== FUTURE PLANS ===

* Test/Stabilize UEFI Self-Certification Tests (SCT) results

=== BUILDING OVMF ===

Pre-requisites:
* Build environment capable of build the edk2 MdeModulePkg.
* A properly configured ASL compiler:
  - Intel ASL compiler: Available from http://www.acpica.org
  - Microsoft ASL compiler: Available from http://www.acpi.info

Update Conf/target.txt ACTIVE_PLATFORM for OVMF:
                             PEI arch   DXE arch   UEFI interfaces
* OvmfPkg/OvmfPkgIa32.dsc      IA32       IA32           IA32
* OvmfPkg/OvmfPkgIa32X64.dsc   IA32       X64            X64
* OvmfPkg/OvmfPkgX64.dsc       X64        X64            X64

Update Conf/target.txt TARGET_ARCH based on the .dsc file:
                             TARGET_ARCH
* OvmfPkg/OvmfPkgIa32.dsc     IA32
* OvmfPkg/OvmfPkgIa32X64.dsc  IA32 X64
* OvmfPkg/OvmfPkgX64.dsc      X64

Following the edk2 build process, you will find the OVMF binaries
under the $WORKSPACE/Build/*/*/FV directory.  The actual path will
depend on how your build is configured.  You can expect to find
these binary outputs:
* OVMF.FD
  - Please note!  This filename has changed.  Older releases used OVMF.Fv.
* OvmfVideo.rom
  - This file is not built separately any longer, starting with svn r13520.

More information on building OVMF can be found at:

http://sourceforge.net/apps/mediawiki/tianocore/index.php?title=How_to_build_OVMF

=== 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.
  (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
    * QEMU/OVMF will use emulated flash, and fully support UEFI variables
    * Run qemu with: -pflash path/to/OVMF.fd
  - Option 2: Use QEMU -bios parameter
    * Note that UEFI variables will be partially emulated, and non-volatile
      variables may lose their contents after a reboot
    * Run qemu with: -bios path/to/OVMF.fd
  - Option 3: Use QEMU -L parameter
    * Note that UEFI variables will be partially emulated, and non-volatile
      variables may lose their contents after a reboot
    * Either copy, rename or symlink OVMF.fd => bios.bin
    * Use the QEMU -L parameter to specify the directory where the bios.bin
      file is located.
* The EFI shell is built into OVMF builds at this time, so it should
  run automatically if a UEFI boot application is not found on the
  removable media.
* On Linux, newer version of QEMU may enable KVM feature, and this might
  cause OVMF to fail to boot.  The QEMU '-no-kvm' may allow OVMF to boot.
* Capturing OVMF debug messages on qemu:
  - The default OVMF build writes debug messages to IO port 0x402.  The
    following qemu command line options save them in the file called
    debug.log: '-debugcon file:debug.log -global isa-debugcon.iobase=0x402'.
  - It is possible to revert to the original behavior, when debug messages were
    written to the emulated serial port (potentially intermixing OVMF debug
    output with UEFI serial console output).  For this the
    '-D DEBUG_ON_SERIAL_PORT' option has to be passed to the build command (see
    the next section), and in order to capture the serial output qemu needs to
    be started with eg. '-serial file:serial.log'.
  - Debug messages fall into several categories.  Logged vs. suppressed
    categories are controlled at OVMF build time by the
    'gEfiMdePkgTokenSpaceGuid.PcdDebugPrintErrorLevel' bitmask (an UINT32
    value) in the selected .dsc file.  Individual bits of this bitmask are
    defined in <MdePkg/Include/Library/DebugLib.h>.  One non-default bit (with
    some performance impact) that is frequently set for debugging is 0x00400000
    (DEBUG_VERBOSE).
  - The RELEASE build target ('-b RELEASE' build option, see below) disables
    all debug messages.  The default build target is DEBUG.

=== Build Scripts ===

On systems with the bash shell you can use OvmfPkg/build.sh to simplify
building and running OVMF.

So, for example, to build + run OVMF X64:
$ OvmfPkg/build.sh -a X64
$ 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

=== Network Support ===

OVMF provides a UEFI network stack by default. Its lowest level driver is the
NIC driver, higher levels are generic. In order to make DHCP, PXE Boot, and eg.
socket test utilities from the StdLib edk2 package work, (1) qemu has to be
configured to emulate a NIC, (2) a matching UEFI NIC driver must be available
when OVMF boots.

(If a NIC is configured for the virtual machine, and -- dependent on boot order
-- PXE booting is attempted, but no DHCP server responds to OVMF's DHCP
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.

* Use the qemu -netdev and -device options, or the legacy -net option, to
  enable NIC support: <http://wiki.qemu.org/Documentation/Networking>.

* 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.

* 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:

  - download a >= 1.5.0-rc1 source tarball from <http://wiki.qemu.org/Download>,

  - 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):

    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

  - extend the NIC's -device option on the qemu command line with a matching
    "romfile=" optarg:

    -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

* Independently of the iPXE NIC drivers, the default OVMF build provides a
  basic virtio-net driver, located in OvmfPkg/VirtioNetDxe.

* Also independently of the iPXE NIC drivers, Intel's proprietary E1000 NIC
  driver (PROEFI) can be embedded in the OVMF image at build time:

  - 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.

  - 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".

* 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:

                 | e1000  ne2k_pci  pcnet  rtl8139  virtio-net-pci
    -------------+------------------------------------------------
    iPXE         |   x       x        x       x           x
    VirtioNetDxe |                                        x
    Intel PROEFI |   x

=== 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).

The layout of the firmware device in memory looks like:

+--------------------------------------- 4GB (0x100000000)
| VTF0 (16-bit reset code) and OVMF SEC
| (SECFV)
+--------------------------------------- varies based on flash size
|
| Compressed main firmware image
| (FVMAIN_COMPACT)
|
+--------------------------------------- base + 0x20000
| Fault-tolerant write (FTW)
| Spare blocks (64KB/0x10000)
+--------------------------------------- base + 0x10000
| FTW Work block (4KB/0x1000)
+--------------------------------------- base + 0x0f000
| Event log area (4KB/0x1000)
+--------------------------------------- base + 0x0e000
| Non-volatile variable storage
| 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.

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 {
    <BuildOptions>
      GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG
  }
  IntelFrameworkModulePkg/Universal/BdsDxe/BdsDxe.inf {
    <BuildOptions>
      GCC:*_*_*_CC_FLAGS             = -UMDEPKG_NDEBUG
  }