audk/OvmfPkg
jljusten e678f9db89 OvmfPkg/SerializeVariablesLib: ignore secure variable restore errors
OvmfPkg's file-based NvVar storage is read back as follows at boot (all
paths under OvmfPkg/Library/):

PlatformBdsPolicyBehavior() [PlatformBdsLib/BdsPlatform.c]
  PlatformBdsRestoreNvVarsFromHardDisk()
    VisitAllInstancesOfProtocol
      for each simple file system:
        VisitingFileSystemInstance()
          ConnectNvVarsToFileSystem() [NvVarsFileLib/NvVarsFileLib.c]
            LoadNvVarsFromFs() [NvVarsFileLib/FsAccess.c]
              ReadNvVarsFile()
+-------------> SerializeVariablesSetSerializedVariables() [SerializeVariablesLib/SerializeVariablesLib.c]
|                 SerializeVariablesIterateInstanceVariables()
|   +-------------> IterateVariablesInBuffer()
|   |                 for each loaded / deserialized variable:
| +-|-----------------> IterateVariablesCallbackSetSystemVariable()
| | |                     gRT->SetVariable()
| | |
| | IterateVariablesInBuffer() stops processing variables as soon as the
| | first error is encountered from the callback function.
| |
| | In this case the callback function is
| IterateVariablesCallbackSetSystemVariable(), selected by
SerializeVariablesSetSerializedVariables().

The result is that no NvVar is restored from the file after the first
gRT->SetVariable() failure.

On my system such a failure
- never happens in an OVMF build with secure boot disabled,
- happens *immediately* with SECURE_BOOT_ENABLE, because the first
  variable to restore is "AuthVarKeyDatabase".

"AuthVarKeyDatabase" has the EFI_VARIABLE_AUTHENTICATED_WRITE_ACCESS
attribute set. Since the loop tries to restore it before any keys (PK, KEK
etc) are enrolled, gRT->SetVariable() rejects it with
EFI_SECURITY_VIOLATION. Consequently the NvVar restore loop terminates
immediately, and we never reach non-authenticated variables such as
Boot#### and BootOrder.

Until work on KVM-compatible flash emulation converges between qemu and
OvmfPkg, improve the SECURE_BOOT_ENABLE boot experience by masking
EFI_SECURITY_VIOLATION in the callback:
- authenticated variables continue to be rejected same as before, but
- at least we allow the loop to progress and restore non-authenticated
  variables, for example boot options.

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://edk2.svn.sourceforge.net/svnroot/edk2/trunk/edk2@14390 6f19259b-4bc3-4df7-8a09-765794883524
2013-05-28 17:21:37 +00:00
..
AcpiPlatformDxe OvmfPkg/AcpiPlatformDxe: split S3/S4 package into bytes 2013-02-14 19:20:57 +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 Add missing braces around initializer. 2012-10-11 02:15:23 +00:00
Include OvmfPkg: adapt VirtioFlush()'s leading comment to the coding style 2013-05-15 06:23:22 +00:00
Library OvmfPkg/SerializeVariablesLib: ignore secure variable restore errors 2013-05-28 17:21:37 +00:00
PlatformPei OvmfPkg: key PMBA setup in Platform PEI off of PMREGMISC/PMIOSE, not Xen 2012-09-12 07:19:28 +00:00
QemuVideoDxe QemuVideo: stdvga mmio bar support 2012-11-27 19:11:45 +00:00
Sec OvmfPkg: Remove variables that are set, but not used 2011-10-31 15:57:12 +00:00
SecureBootConfigDxe Update file guid to avoid conflict with other file. 2012-08-17 05:31:47 +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: VirtioBlkDriverBindingStop: fix incorrect use of UEFI driver model 2012-10-18 17:07:24 +00:00
VirtioScsiDxe OvmfPkg VirtioScsiDxe: Fix build with VS2010 2012-10-23 22:16:14 +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: Add LoadLinuxLib library interface 2012-11-02 18:26:48 +00:00
OvmfPkgIa32.dsc OvmfPkg: enable the generic network stack by default 2013-05-15 18:20:39 +00:00
OvmfPkgIa32.fdf OvmfPkg: enable the generic network stack by default 2013-05-15 18:20:39 +00:00
OvmfPkgIa32X64.dsc OvmfPkg: enable the generic network stack by default 2013-05-15 18:20:39 +00:00
OvmfPkgIa32X64.fdf OvmfPkg: enable the generic network stack by default 2013-05-15 18:20:39 +00:00
OvmfPkgX64.dsc OvmfPkg: enable the generic network stack by default 2013-05-15 18:20:39 +00:00
OvmfPkgX64.fdf OvmfPkg: enable the generic network stack by default 2013-05-15 18:20:39 +00:00
README OvmfPkg: enable the generic network stack by default 2013-05-15 18:20:39 +00:00
build.sh OvmfPkg: update qemu-executable for IA32 2013-01-25 16:22:07 +00:00
create-release.py OvmfPkg: remove OvmfVideo.rom references 2013-04-03 18:20:57 +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 status: Alpha

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

* Stabilize UEFI Linux boot
* 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.9.1 or later is required.
* Either copy, rename or symlink OVMF.FD => bios.bin
* 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 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 generic UEFI network stack by default, with the lowest level
driver (the NIC driver) missing in the default build. In order to complete the
stack and make eg. DHCP, PXE Boot, and 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).

* 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 drivers are available from the default
  qemu installation to OVMF without further settings.

* 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 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, Intel's proprietary E1000 NIC driver
  can be embedded in the OVMF image at build time, as an alternative guest
  driver for "-device e1000":

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

=== 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
  }