Commit Graph

349 Commits

Author SHA1 Message Date
Ard Biesheuvel de7c6081cb OvmfPkg: add new QEMU kernel image loader components
Add the components that expose the QEMU abstract loader file system so
that we can switch over our PlatformBmLib over to it in a subsequent
patch.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2566
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-05 19:45:05 +00:00
Laszlo Ersek 55942db1d3 OvmfPkg: clone CpuS3DataDxe from UefiCpuPkg
The @file comments in UefiCpuPkg/CpuS3DataDxe say,

  [...] It also only supports the number of CPUs reported by the MP
  Services Protocol, so this module does not support hot plug CPUs.  This
  module can be copied into a CPU specific package and customized if these
  additional features are required. [...]

The driver is so small that the simplest way to extend it with hotplug
support is indeed to clone it at first. In this patch, customize the
driver only with the following no-op steps:

- Update copyright notices.
- Update INF_VERSION to the latest INF spec version (1.29).
- Update FILE_GUID.
- Drop the UNI files.
- Replace EFI_D_VERBOSE with DEBUG_VERBOSE, to appease "PatchCheck.py".

This patch is best reviewed with:

$ git show --find-copies-harder

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-15-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-04 12:22:07 +00:00
Laszlo Ersek 17efae27ac OvmfPkg/CpuHotplugSmm: introduce skeleton for CPU Hotplug SMM driver
Add a new SMM driver skeleton that registers a root SMI handler, and
checks if the SMI control value (written to 0xB2) indicates a CPU hotplug
SMI.

QEMU's ACPI payload will cause the OS to raise a broadcast SMI when a CPU
hotplug event occurs, namely by writing value 4 to IO Port 0xB2. In other
words, control value 4 is now allocated for this purpose; introduce the
ICH9_APM_CNT_CPU_HOTPLUG macro for it.

The standard identifiers in this driver use the new MM (Management Mode)
terminology from the PI spec, not the earlier SMM (System Management Mode)
terms.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-7-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-04 12:22:07 +00:00
Laszlo Ersek 49df3fcee1 OvmfPkg: enable CPU hotplug support in PiSmmCpuDxeSmm
Set "PcdCpuHotPlugSupport" to TRUE, when OVMF is built with SMM_REQUIRE.
Consequences:

(1) In PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c],
    resources are allocated and populated in advance for all possible
    (i.e., potentially hot-added) processors, rather than only the
    processors present at boot.

    The possible count (called "mMaxNumberOfCpus") is set from
    "PcdCpuMaxLogicalProcessorNumber"; we set the latter in
    OvmfPkg/PlatformPei. (Refer to commit 83357313dd,
    "OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU
    hotplug", 2020-01-29).

(2) The AddProcessor() and RemoveProcessor() member functions of
    EFI_SMM_CPU_SERVICE_PROTOCOL, implemented in
    "UefiCpuPkg/PiSmmCpuDxeSmm/CpuService.c", are no longer
    short-circuited to EFI_UNSUPPORTED.

    We'll rely on these functions in the CPU hotplug SMI handler, in a
    subsequent patch.

(3) In PiCpuSmmEntry(), the address of the CPU_HOT_PLUG_DATA structure (in
    SMRAM) is exposed via the dynamic-only "PcdCpuHotPlugDataAddress".

    This structure is an information channel between the CPU hotplug SMI
    handler, and EFI_SMM_CPU_SERVICE_PROTOCOL. Namely, at the first
    "Index" where the following equality holds:

      CPU_HOT_PLUG_DATA.ApicId[Index] == INVALID_APIC_ID

    a hot-plugged CPU can be accepted, with the steps below:

(3.1) The hotplug SMI handler has to overwrite INVALID_APIC_ID with the
      new CPU's APIC ID.

(3.2) The new CPU's SMBASE has to be relocated to:

        CPU_HOT_PLUG_DATA.SmBase[Index]

      (which was precomputed in step (1) above).

(3.3) The hotplug SMI handler is supposed to call
      EFI_SMM_CPU_SERVICE_PROTOCOL.AddProcessor().

Note: we need not spell out "PcdCpuHotPlugDataAddress" in the
[PcdsDynamicDefault] sections of the OVMF DSC files, just so the PCD
become dynamically settable. That's because "UefiCpuPkg.dec" declares this
PCD with [PcdsDynamic, PcdsDynamicEx] access methods *only*.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-6-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-04 12:22:07 +00:00
Laszlo Ersek 43df61878d OvmfPkg: enable SMM Monarch Election in PiSmmCpuDxeSmm
With "PcdCpuSmmEnableBspElection" set to FALSE, PiSmmCpuDxeSmm always
considers the processor with index 0 to be the SMM Monarch (a.k.a. the SMM
BSP). The SMM Monarch handles the SMI for real, while the other CPUs wait
in their SMM loops.

In a subsequent patch, we want to set "PcdCpuHotPlugSupport" to TRUE. For
that, PiCpuSmmEntry() [UefiCpuPkg/PiSmmCpuDxeSmm/PiSmmCpuDxeSmm.c] forces
us with an ASSERT() to set "PcdCpuSmmEnableBspElection" to TRUE as well.
To satisfy that expectation, we can simply remove our current
"PcdCpuSmmEnableBspElection|FALSE" setting, and inherit the default TRUE
value from "UefiCpuPkg.dec".

This causes "mSmmMpSyncData->BspIndex" in PiSmmCpuDxeSmm to lose its
static zero value (standing for CPU#0); instead it becomes (-1) in
general, and the SMM Monarch is elected anew on every SMI.

The default SMM Monarch Election is basically a race -- whichever CPU can
flip "mSmmMpSyncData->BspIndex" from (-1) to its own index, becomes king,
for handling that SMI. Refer to SmiRendezvous()
[UefiCpuPkg/PiSmmCpuDxeSmm/MpService.c].

I consider this non-determinism less than ideal on QEMU/KVM; it would be
nice to stick with a "mostly permanent" SMM Monarch even with the Election
enabled. We can do that by implementing the PlatformSmmBspElection() API
in the SmmCpuPlatformHookLibQemu instance:

The IA32 APIC Base MSR can be read on each CPU concurrently, and it will
report the BSP bit as set only on the current Boot Service Processor. QEMU
marks CPU#0 as the BSP, by default.

Elect the current BSP, as reported by QEMU, for the SMM Monarch role.

(Note that the QEMU commit history is not entirely consistent on whether
QEMU/KVM may mark a CPU with nonzero index as the BSP:

- At tag v4.2.0, "target/i386/cpu.c" has a comment saying "We hard-wire
  the BSP to the first CPU". This comment goes back to commit 6cb2996cef5e
  ("x86: Extend validity of bsp_to_cpu", 2010-03-04).

- Compare commit 9cb11fd7539b ("target-i386: clear bsp bit when
  designating bsp", 2015-04-02) though, especially considering KVM.

Either way, this OvmfPkg patch is *not* dependent on CPU index 0; it just
takes the race on every SMI out of the game.)

One benefit of using a "mostly permanent" SMM Monarch / BSP is that we can
continue testing the SMM CPU synchronization by deterministically entering
the firmware on the BSP, vs. on an AP, from Linux guests:

$ time taskset -c 0 efibootmgr
$ time taskset -c 1 efibootmgr

(See
<https://github.com/tianocore/tianocore.github.io/wiki/Testing-SMM-with-QEMU,-KVM-and-libvirt#uefi-variable-access-test>.)

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Suggested-by: Igor Mammedov <imammedo@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512#c5
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-5-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-04 12:22:07 +00:00
Laszlo Ersek c69f6406b9 OvmfPkg: clone SmmCpuPlatformHookLib from UefiCpuPkg
Clone the Null instance of SmmCpuPlatformHookLib from UefiCpuPkg to
OvmfPkg. In this patch, customize the lib instance only with the following
no-op steps:

- Replace Null/NULL references in filenames and comments with Qemu/QEMU
  references.
- Update copyright notices.
- Clean up and rewrap comment blocks.
- Update INF_VERSION to the latest INF spec version (1.29).
- Update FILE_GUID.
- Drop the UNI file.

This patch is best reviewed with:

$ git show --find-copies=43 --find-copies-harder

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226221156.29589-4-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Tested-by: Boris Ostrovsky <boris.ostrovsky@oracle.com>
2020-03-04 12:22:07 +00:00
Marc-André Lureau 61d3b2d427 OvmfPkg: plug DxeTpmMeasureBootLib into SecurityStubDxe
Mirrors TPM 2.0 commit d5a002aba0 ("OvmfPkg: plug
DxeTpm2MeasureBootLib into SecurityStubDxe", 2018-03-09)

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-6-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
2020-03-04 12:22:07 +00:00
Marc-André Lureau fc0a025ec3 OvmfPkg: include TcgDxe module
Mirrors TPM 2.0 commit 0c0a50d6b3 ("OvmfPkg: include Tcg2Dxe
module", 2018-03-09).

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-5-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
2020-03-04 12:22:07 +00:00
Marc-André Lureau 6be54f15a0 OvmfPkg: include TcgPei module
Mirrors TPM 2.0 commit 4672a48928 ("OvmfPkg: include Tcg2Pei
module", 2018-03-09).

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-4-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
2020-03-04 12:22:07 +00:00
Marc-André Lureau 8923699291 OvmfPkg: detect TPM 1.2 in Tcg2ConfigPei
Complement commit 6cf1880fb5 ("OvmfPkg: add customized Tcg2ConfigPei
clone", 2018-03-09) by detecting TPM 1.2 devices.

Since Tpm12RequestUseTpm() returns success on any TPM interface,
(including FIFO & CRB which are TPM 2.0), try to send a GetTicks TPM
1.2 command to probe the version. In case of failure, fallback on TPM
2.0 path.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Stefan Berger <stefanb@linux.ibm.com>
Message-Id: <20200226152433.1295789-3-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
2020-03-04 12:22:07 +00:00
Marc-André Lureau 07952a962a OvmfPkg: rename TPM2 config prefix to TPM
A following patch is going to use the same configuration for TPM1.2
and TPM2.0, and it's simpler to support both than variable
configurations.

Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200226152433.1295789-2-marcandre.lureau@redhat.com>
Tested-by: Simon Hardy <simon.hardy@itdev.co.uk>
2020-03-04 12:22:07 +00:00
Ard Biesheuvel d55cfdc51f OvmfPkg IA32: add support for loading X64 images
This is the UEFI counterpart to my Linux series which generalizes
mixed mode support into a feature that requires very little internal
knowledge about the architecture specifics of booting Linux on the
part of the bootloader or firmware.

Instead, we add a .compat PE/COFF header containing an array of
PE_COMPAT nodes containing <machine type, entrypoint> tuples that
describe alternate entrypoints into the image for different native
machine types, e.g., IA-32 in a 64-bit image so it can be booted
from IA-32 firmware.

This patch implements the PE/COFF emulator protocol to take this new
section into account, so that such images can simply be loaded via
LoadImage/StartImage, e.g., straight from the shell.

This feature is based on the EDK2 specific PE/COFF emulator protocol
that was introduced in commit 57df17fe26 ("MdeModulePkg/DxeCore:
invoke the emulator protocol for foreign images", 2019-04-14).

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 09:26:45 +00:00
Ard Biesheuvel ec41733cfd OvmfPkg: add the 'initrd' dynamic shell command
Add the 'initrd' dynamic shell command to the build so we can load
Linux initrds straight from the shell using the new generic protocol,
which does not rely on initrd= being passed on the command line.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=2564
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-03-04 09:26:45 +00:00
Laszlo Ersek 50f911d25d OvmfPkg: introduce PcdCsmEnable feature flag
In the DXE phase and later, it is possible for a module to dynamically
determine whether a CSM is enabled. An example can be seen in commit
855743f717 ("OvmfPkg: prevent 64-bit MMIO BAR degradation if there is no
CSM", 2016-05-25).

SEC and PEI phase modules cannot check the Legacy BIOS Protocol however.
For their sake, introduce a new feature PCD that simply reflects the
CSM_ENABLE build flag.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien@xen.org>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200129214412.2361-11-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-02-05 12:59:32 +00:00
Laszlo Ersek d74d56fcfa OvmfPkg: introduce PcdQ35SmramAtDefaultSmbase
For supporting VCPU hotplug with SMM enabled/required, QEMU offers the
(dynamically detectable) feature called "SMRAM at default SMBASE". When
the feature is enabled, the firmware can lock down the 128 KB range
starting at the default SMBASE; that is, the [0x3_0000, 0x4_FFFF]
interval. The goal is to shield the very first SMI handler of the
hotplugged VCPU from OS influence.

Multiple modules in OVMF will have to inter-operate for locking down this
range. Introduce a dynamic PCD that will reflect the feature (to be
negotiated by PlatformPei), for coordination between drivers.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1512
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Message-Id: <20200129214412.2361-2-lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-02-05 12:59:32 +00:00
Laszlo Ersek 83357313dd OvmfPkg/PlatformPei: rewrite MaxCpuCountInitialization() for CPU hotplug
MaxCpuCountInitialization() currently handles the following options:

(1) QEMU does not report the boot CPU count (FW_CFG_NB_CPUS is 0)

    In this case, PlatformPei makes MpInitLib enumerate APs up to the
    default PcdCpuMaxLogicalProcessorNumber value (64) minus 1, or until
    the default PcdCpuApInitTimeOutInMicroSeconds (50,000) elapses.
    (Whichever is reached first.)

    Time-limited AP enumeration had never been reliable on QEMU/KVM, which
    is why commit 45a70db3c3 strated handling case (2) below, in OVMF.

(2) QEMU reports the boot CPU count (FW_CFG_NB_CPUS is nonzero)

    In this case, PlatformPei sets

    - PcdCpuMaxLogicalProcessorNumber to the reported boot CPU count
      (FW_CFG_NB_CPUS, which exports "PCMachineState.boot_cpus"),

    - and PcdCpuApInitTimeOutInMicroSeconds to practically "infinity"
      (MAX_UINT32, ~71 minutes).

    That causes MpInitLib to enumerate exactly the present (boot) APs.

    With CPU hotplug in mind, this method is not good enough. Because,
    using QEMU terminology, UefiCpuPkg expects
    PcdCpuMaxLogicalProcessorNumber to provide the "possible CPUs" count
    ("MachineState.smp.max_cpus"), which includes present and not present
    CPUs both (with not present CPUs being subject for hot-plugging).
    FW_CFG_NB_CPUS does not include not present CPUs.

Rewrite MaxCpuCountInitialization() for handling the following cases:

(1) The behavior of case (1) does not change. (No UefiCpuPkg PCDs are set
    to values different from the defaults.)

(2) QEMU reports the boot CPU count ("PCMachineState.boot_cpus", via
    FW_CFG_NB_CPUS), but not the possible CPUs count
    ("MachineState.smp.max_cpus").

    In this case, the behavior remains unchanged.

    The way MpInitLib is instructed to do the same differs however: we now
    set the new PcdCpuBootLogicalProcessorNumber to the boot CPU count
    (while continuing to set PcdCpuMaxLogicalProcessorNumber identically).
    PcdCpuApInitTimeOutInMicroSeconds becomes irrelevant.

(3) QEMU reports both the boot CPU count ("PCMachineState.boot_cpus", via
    FW_CFG_NB_CPUS), and the possible CPUs count
    ("MachineState.smp.max_cpus").

    We tell UefiCpuPkg about the possible CPUs count through
    PcdCpuMaxLogicalProcessorNumber. We also tell MpInitLib the boot CPU
    count for precise and quick AP enumeration, via
    PcdCpuBootLogicalProcessorNumber. PcdCpuApInitTimeOutInMicroSeconds is
    irrelevant again.

This patch is a pre-requisite for enabling CPU hotplug with SMM_REQUIRE.
As a side effect, the patch also enables S3 to work with CPU hotplug at
once, *without* SMM_REQUIRE.

(Without the patch, S3 resume fails, if a CPU is hot-plugged at OS
runtime, prior to suspend: the FW_CFG_NB_CPUS increase seen during resume
causes PcdCpuMaxLogicalProcessorNumber to increase as well, which is not
permitted.

With the patch, PcdCpuMaxLogicalProcessorNumber stays the same, namely
"MachineState.smp.max_cpus". Therefore, the CPU structures allocated
during normal boot can accommodate the CPUs at S3 resume that have been
hotplugged prior to S3 suspend.)

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Igor Mammedov <imammedo@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1515
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20191022221554.14963-4-lersek@redhat.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2020-01-29 17:28:22 +00:00
Ard Biesheuvel f55477fe2d OvmfPkg: use HII type PCDs for TPM2 config related variables
The HII pages that are part of Tcg2ConfigDxe expect the following PCDs
to be of dynamic HII type, so declare them as such.

  gEfiSecurityPkgTokenSpaceGuid.PcdTcgPhysicalPresenceInterfaceVer
  gEfiSecurityPkgTokenSpaceGuid.PcdTpm2AcpiTableRev

Currently, the TPM2 ACPI table is not produced, since we do not
incorporate the Tcg2Smm module, which implements the SMI based
physical presence interface exposed to the OS.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-09 13:13:28 +00:00
Ard Biesheuvel cf3ad972a2 OvmfPkg: reorganize TPM2 support in DSC/FDF files
Put the TPM2 related DXE modules together in the DSC, and add a
TPM2 support header comment while at it.

Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2020-01-09 13:13:28 +00:00
Liming Gao 0769224ac7 OvmfPkg DSC: Update tool chain name to CLANGPDB
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=2341

Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-11-15 06:04:21 +00:00
Michael Kubacki d511d6e0e7 OvmfPkg: Disable variable runtime cache
Sets gEfiMdeModulePkgTokenSpaceGuid.PcdEnableVariableRuntimeCache
to FALSE in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc, and OvmfPkgX64.dsc
so that when SMM_REQUIRE is TRUE, the SMM variable driver will not
use the runtime variable cache.

This is done for OvmfPkg because it currently depends upon a SMM
variable GetVariable ()implementation as a simple method to exercise
the SMM driver stack. This allows the following commands to be used
for variables such as Boot####, BootOrder, and BootNext to test SMM
timing and stability differences on the BSP (e.g. CPU#0) vs an
AP (e.g. CPU#1).
 # taskset -c 0 efibootmgr
 # taskset -c 1 efibootmgr

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Signed-off-by: Michael Kubacki <michael.a.kubacki@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-11-05 21:55:54 -08:00
Liming Gao 703232b8e8 OvmfPkg: Enable CLANG9 tool chain
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1603
1. Apply CLANG9 Linker option.
2. Exclude -mno-mmx -mno-sse compiler option for CLANG9
These two options will cause CLANG Linker crush.

Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-10-24 09:41:35 +08:00
Peter Jones 46bb812007 OvmfPkg: Make SOURCE_DEBUG_ENABLE actually need to be set to TRUE
Currently some tests check the value of SOURCE_DEBUG_ENABLE, and some
tests check if it's defined or not.  Additionally, in UefiPayloadPkg as
well as some other trees, we define it as FALSE in the .dsc file.

This patch changes all of the Ovmf platforms to explicitly define it as
FALSE by default, and changes all of the checks to test if the value is
TRUE.

Signed-off-by: Peter Jones <pjones@redhat.com>
Message-Id: <20190920184507.909884-1-pjones@redhat.com>
[lersek@redhat.com: drop Contributed-under line, per TianoCore BZ#1373]
[lersek@redhat.com: replace "!= TRUE" with more idiomatic "== FALSE"]
Cc: Andrew Fish <afish@apple.com>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Peter Jones <pjones@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
Acked-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-10-22 20:22:04 +02:00
Anthony PERARD 3afa2ed53f OvmfPkg/AcpiPlatformDxe: Use XenPlatformLib
This patch replace the XenDetected() function by the one in
XenPlatformLib.

Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1689
Signed-off-by: Anthony PERARD <anthony.perard@citrix.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190813113119.14804-15-anthony.perard@citrix.com>
2019-08-21 18:03:49 +02:00
Imran Desai 5d3ef15da7 OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781
GITHUB: https://github.com/idesai/edk2/tree/enable_sm3_measured_boot_v6

EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR
banks. This digest algorithm is part of the China Crypto algorithm suite.
This integration has dependency on the openssl_1_1_1b integration into
edk2.

This patch links SM3 support into Tcg2Pei and Tcg2Dxe.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>

Signed-off-by: Imran Desai <imran.desai@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190718225326.40839-5-imran.desai@intel.com>
Acked-by: Jiewen Yao <jiewen.yao@intel.com>
2019-07-19 14:32:02 +02:00
Laszlo Ersek ddc020fb0a Revert "OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe"
This reverts commit a7c7d21ffa.

The reason is that said commit had not been reviewed by OvmfPkg
maintainers/reviewers, before it was pushed.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Imran Desai <imran.desai@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1781
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-07-04 17:48:08 +02:00
Gary Lin 1ec05b81e5 OvmfPkg: use DxeTpmMeasurementLib if and only if TPM2_ENABLE
(a) OvmfPkg first had to resolve the TpmMeasurementLib class -- for
    SECURE_BOOT_ENABLE only -- when the DxeImageVerificationLib instance
    became dependent on TpmMeasurementLib. For details, refer to commit
    0d28d286bf ("OvmfPkg: resolve TpmMeasurementLib dependency
    introduced in r14687", 2013-09-21).

(b) At the time, only one instance of TpmMeasurementLib existed, namely
    DxeTpmMeasurementLib. This lib instance didn't do anything -- like it
    was desirable for OVMF --, because OVMF didn't include any Tcg / TrEE
    protocol implementations.

(c) In commit 308521b133 ("MdeModulePkg: Move TpmMeasurementLib
    LibraryClass from SecurityPkg", 2015-07-01), TpmMeasurementLibNull was
    introduced.

(d) In commit 285542ebbb ("OvmfPkg: Link AuthVariableLib for following
    merged variable driver deploy", 2015-07-01), a TpmMeasurementLib
    resolution became necessary regardless of SECURE_BOOT_ENABLE. And so
    TpmMeasurementLib was resolved to TpmMeasurementLibNull in OVMF, but
    only in the non-SECURE_BOOT_ENABLE case. This step -- possibly, the
    larger series containing commit 285542ebbb -- missed an opportunity
    for simplification: given (b), the DxeTpmMeasurementLib instance
    should have been simply replaced with the TpmMeasurementLibNull
    instance, regardless of SECURE_BOOT_ENABLE.

(e) In commit 1abfa4ce48 ("Add TPM2 support defined in trusted computing
    group.", 2015-08-13), the TrEE dependency was replaced with a Tcg2
    dependency in DxeTpmMeasurementLib.

(f) Starting with commit 0c0a50d6b3 ("OvmfPkg: include Tcg2Dxe module",
    2018-03-09), OVMF would include a Tcg2 protocol implementation,
    thereby satisfying DxeTpmMeasurementLib's dependency. With
    TPM2_ENABLE, it would actually make sense to consume
    DxeTpmMeasurementLib -- however, DxeTpmMeasurementLib would never be
    used without SECURE_BOOT_ENABLE.

Therefore, we have the following four scenarios:

- TPM2_ENABLE + SECURE_BOOT_ENABLE: works as expected.

- Neither enabled: works as expected.

- Only TPM2_ENABLE: this build is currently incorrect, because
  Variable/RuntimeDxe consumes TpmMeasurementLib directly, but
  TpmMeasureAndLogData() will never reach the TPM because we link
  TpmMeasurementLibNull into the variable driver. This is a problem from
  the larger series containing (f).

- Only SECURE_BOOT_ENABLE: this build works as expected, but it is
  wasteful -- given that the protocol database will never contain Tcg2
  without TPM2_ENABLE, we should simply use TpmMeasurementLibNull. This is
  a problem from (d).

Resolving TpmMeasurementLib to DxeTpmMeasurementLib as a function of
*only* TPM2_ENABLE, we can fix / optimize the last two cases.

v2:
  - Amend the title and description suggested by Laszlo
  - Move TpmMeasurementLib to the existed TPM2_ENABLE block

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Signed-off-by: Gary Lin <glin@suse.com>
Message-Id: <20190704040731.5303-1-glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-07-04 15:42:45 +02:00
Imran Desai a7c7d21ffa OvmfPkg: link SM3 support into Tcg2Pei and Tcg2Dxe
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=1781

EDK2 Support for SM3 digest algorithm is needed to enable TPM with SM3 PCR
banks. This digest algorithm is part of the China Crypto algorithm suite.
This integration has dependency on the openssl_1_1_1b integration into
edk2.
This patch links SM3 support into Tcg2Pei and Tcg2Dxe.

Signed-off-by: Imran Desai <imran.desai@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Cc: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: jiewen.yao@intel.com
2019-07-03 16:31:56 +08:00
David Woodhouse 4b04d9d736 OvmfPkg: Don't build in QemuVideoDxe when we have CSM
QemuVideoDxe installs its own legacy INT 10h handler for the benefit of
systems like Windows 2008r2 which attempt to use INT 10h even when booted
via EFI.

This interacts extremely badly with a CSM actually attempting to install
a real video BIOS.

The last thing done before invoking a legacy OpROM is to call INT 10h to
set a plain text mode. In the case where it's the video BIOS OpROM being
loaded, INT 10h will normally point to an iret stub in the CSM itself.

Unless QemuVideoDxe has changed INT10h to point to a location in the
0xC0000 segment that it didn't allocate properly, so the real OpROM has
been shadowed over them top of it, and the INT 10h vector now points to
some random place in the middle of the newly-shadowed OpROM.

Don't Do That Then. QemuVideoDxe doesn't do any acceleration and just
sets up a linear framebuffer, so we don't lose much by just
unconditionally using BiosVideoDxe instead when CSM is present.

Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-4-dwmw2@infradead.org>
2019-06-26 15:06:44 +02:00
Hao A Wu 84f736a73e OvmfPkg: Refer to Shell app via its declared GUID
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1843

Currently, the file GUID reference of the UEFI Shell app is indirected
via the PCD gEfiIntelFrameworkModulePkgTokenSpaceGuid.PcdShellFile,
which is set to a fixed value for OvmfPkg.

So instead, use the symbolic GUID in ShellPkg for this purpose, and drop
the reference to this PCD, and to the IntelFrameworkModulePkg package
entirely.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-06-17 09:27:32 +08:00
Hao A Wu 3207a872a4 OvmfPkg: Update DSC/FDF files to consume CSM components in OvmfPkg
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1811

This commit updates the OVMF DSC/FDF files to consume the copied CSM
components within OvmfPkg.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-06-14 13:05:48 +08:00
Hao A Wu 5626887071 OvmfPkg: Drop build flag USE_LEGACY_ISA_STACK and legacy ISA stack
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1842

According to the discussion at:
https://edk2.groups.io/g/devel/topic/30918343#38093

For OVMF, we keep both ISA stacks:
* The legacy one in PcAtChipsetPkg/IntelFrameworkModulePkg
* The Sio bus based OVMF-specified one introduced by commit a5cc178aeb

for a period of time (includes 1 stable tag: edk2-stable201905). And we
also keep the Sio bus based OVMF-specified stack as the default one (via a
build option 'USE_LEGACY_ISA_STACK') to validate its stability.

This commit will propose to drop the legacy ISA stack from OVMF and remove
the usage of the build flag 'USE_LEGACY_ISA_STACK' at the same time. This
is considered as a preparation for the removal of
PcAtChipsetPkg/IsaAcpiDxe & IntelFrameworkModulePkg.

Cc: Ray Ni <ray.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Signed-off-by: Hao A Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-06-11 09:04:53 +08:00
Laszlo Ersek b07de0974b OvmfPkg: raise the PCIEXBAR base to 2816 MB on Q35
(This is a replacement for commit 75136b2954, "OvmfPkg/PlatformPei:
reorder the 32-bit PCI window vs. the PCIEXBAR on q35", 2019-05-16).

Commit 7b8fe63561 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG
/ ECAM) on Q35", 2016-03-10) claimed that,

  On Q35 machine types that QEMU intends to support in the long term, QEMU
  never lets the RAM below 4 GB exceed 2 GB.

Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).

In turn, such a RAM size (justifiedly) triggers

  ASSERT (TopOfLowRam <= PciExBarBase);

in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)

In order to fix this, place the PCIEXBAR at 2816MB (0xB000_0000), and
start the 32-bit PCI window at 3 GB (0xC000_0000). This shrinks the 32-bit
PCI window to

  0xFC00_0000 - 0xC000_0000 = 0x3C00_0000 = 960 MB.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-06-03 19:54:34 +02:00
Laszlo Ersek eb4d62b077 Revert "OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR on q35"
This reverts commit 75136b2954.

The original fix for <https://bugzilla.tianocore.org/show_bug.cgi?id=1814>
triggered a bug / incorrect assumption in QEMU.

QEMU assumes that the PCIEXBAR is below the 32-bit PCI window, not above
it. When the firmware doesn't satisfy this assumption, QEMU generates an
\_SB.PCI0._CRS object in the ACPI DSDT that does not reflect the
firmware's 32-bit MMIO BAR assignments. This causes OSes to re-assign
32-bit MMIO BARs.

Working around the problem in the firmware looks less problematic than
fixing QEMU. Revert the original changes first, before implementing an
alternative fix.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1859
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-06-03 19:54:01 +02:00
Laszlo Ersek 75136b2954 OvmfPkg/PlatformPei: reorder the 32-bit PCI window vs. the PCIEXBAR on q35
Commit 7b8fe63561 ("OvmfPkg: PlatformPei: enable PCIEXBAR (aka MMCONFIG
/ ECAM) on Q35", 2016-03-10) claimed that,

  On Q35 machine types that QEMU intends to support in the long term, QEMU
  never lets the RAM below 4 GB exceed 2 GB.

Alas, this statement came from a misunderstanding that occurred while we
worked out the interface contract. In fact QEMU does allow the 32-bit RAM
extend up to 0xB000_0000 (exclusive), in case the RAM size falls in the
range (0x8000_0000, 0xB000_0000) (i.e., the RAM size is greater than
2048MB and smaller than 2816MB).

In turn, such a RAM size (justifiedly) triggers

  ASSERT (TopOfLowRam <= PciExBarBase);

in MemMapInitialization(), because we placed the 256MB PCIEXBAR at
0x8000_0000 (2GB) exactly, relying on the interface contract. (And, the
32-bit PCI window would follow the PCIEXBAR, covering the [0x9000_0000,
0xFC00_0000) range.)

In order to fix this, reorder the 32-bit PCI window against the PCIEXBAR,
as follows:

- start the 32-bit PCI window where it starts on i440fx as well, that is,
  at 2GB or TopOfLowRam, whichever is higher;

- unlike on i440fx, where the 32-bit PCI window extends up to 0xFC00_0000,
  stop it at 0xE000_0000 on q35,

- place the PCIEXBAR at 0xE000_0000.

(We cannot place the PCIEXBAR at 0xF000_0000 because the 256MB MMIO area
that starts there is not entirely free.)

Before this patch, the 32-bit PCI window used to only *end* at the same
spot (namely, 0xFC00_0000) between i440fx and q35; now it will only
*start* at the same spot (namely, 2GB or TopOfLowRam, whichever is higher)
between both boards.

On q35, the maximal window shrinks from

  0xFC00_0000 - 0x9000_0000 = 0x6C00_0000 == 1728 MB

to

  0xE000_0000 - 0x8000_0000 == 1536 MB.

We lose 192 MB of the aperture; however, the aperture is now aligned at
1GB, rather than 256 MB, and so it could fit a 1GB BAR even.

Regarding the minimal window (triggered by RAM size 2815MB), its size is

  0xE000_0000 - 0xAFF0_0000 = 769 MB

which is not great, but probably better than a failed ASSERT.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gerd Hoffmann <kraxel@redhat.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1814
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1666941
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1701710
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
2019-05-16 21:18:54 +02:00
Fu Siyuan 631195044f OvmfPkg: Update DSC/FDF to use NetworkPkg's include fragment file.
This patch updates the platform DSC/FDF files to use the include fragment
files provided by NetworkPkg.
The feature enabling flags in [Defines] section have been updated to use
the NetworkPkg's terms, and the value has been overridden with the original
default value on this platform.

v2:1.Make the comments before Network definition align other parts.
   2.Set NETWORK_ALLOW_HTTP_CONNECTIONS true.
   3.Remove TcpIoLib in lib classes section.
   4.Withdraw the removal of [PcdsFixedAtBuild.X64].

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Message-Id: <20190516081810.27840-2-shenglei.zhang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293
[lersek@redhat.com: add TianoCore Bugzilla reference]
2019-05-16 16:28:49 +02:00
Zhang, Shenglei a11d371ef6 OvmfPkg: Remove duplicated library classes in dxe drivers section in DSC
NetLib,IpIoLib,UdpIoLib and DpcLib already exist in [LibraryClasses].
So the ones in [LibraryClasses.common.DXE_DRIVER] are duplicated,
which should be removed.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Message-Id: <20190515072419.23792-1-shenglei.zhang@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1293
[lersek@redhat.com: add TianoCore BZ reference]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-05-15 11:08:50 +02:00
Laszlo Ersek b11636239f OvmfPkg: introduce EnrollDefaultKeys application
Add the OvmfPkg/EnrollDefaultKeys shell application source as it is at the
"edk2-20190308git89910a39dcfd-2.el8" tag in RHEL8's downstream "edk2"
package.

Further patches in this series will replace Red Hat-specific bits in the
application, with a conduit to pass in parameters directly from the host
side, on both QEMU and Xen.

(Note: at the moment, Xen doesn't support Secure Boot, due to lacking a
standards-conformant variable driver stack. However, that could change
soon
<https://fosdem.org/2019/schedule/event/vai_implementing_uefi_variable_services_in_qemu/>,
and then this facility will become useful on Xen too.)

The use case for this application (including why it is only being added to
the DSC files) is explained in detail in
<https://bugzilla.tianocore.org/show_bug.cgi?id=1747#c0>.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@arm.com>
Bugzilla: https://bugzilla.tianocore.org/show_bug.cgi?id=1747
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Philippe Mathieu-Daude <philmd@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Gary Lin <glin@suse.com>
2019-04-30 14:26:11 +02:00
Hao Wu 6d70ade90c OvmfPkg: Update DSC/FDF files to consume 8259/8254 drivers in OvmfPkg
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

This commit updates the OVMF DSC/FDF files to consume the copied
8259InterruptControllerDxe and 8254TimerDxe drivers within OvmfPkg.

The unconsumed PCD:
gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel

is removed from DSC files as well.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-11 08:57:30 +08:00
Hao Wu e3c787af8c OvmfPkg/8254TimerDxe: Update to make it build for OVMF
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

This commit will remove the IntelFrameworkPkg DEC file dependency in the
driver INF file.

A new GUID has been updated for the INF file.

Corresponding changes have been made in OVMF DSC files as well in order to
verify the build.

Please note that a subsequent commit (final patch of the series) will:

A) Add OvmfPkg/8254TimerDxe driver in OVMF FDF files;
B) Remove the consumption of PcAtChipsetPkg/8254TimerDxe driver in OVMF
DSC/FDF files.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-11 08:57:29 +08:00
Hao Wu c01852433f OvmfPkg/8259InterruptControllerDxe: Update to make it build for OVMF
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1496

Several updates have been made to the
OvmfPkg/8259InterruptControllerDxe driver to make it build under OvmfPkg:

A) Update the driver INF file to consume PCDs defined within OvmfPkg;
B) Remove the unnecessary dependency on the IntelFrameworkPkg header file
   'FrameworkDxe.h';
C) Remove the IntelFrameworkPkg & PcAtChipsetPkg DEC files dependency in
   the driver INF file.

A new GUID has been updated for the INF file.

Corresponding changes have been made in OVMF DSC files as well in order to
verify the build.

Please note that a subsequent commit (final patch of the series) will:

A) Add OvmfPkg/8259InterruptControllerDxe driver in OVMF FDF files;
B) Remove the consumption of PcAtChipsetPkg/8259InterruptControllerDxe
   driver in OVMF DSC/FDF files;
C) Remove the consumption of
   gPcAtChipsetPkgTokenSpaceGuid.Pcd8259LegacyModeEdgeLevel in OVMF DSC
   files.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: David Woodhouse <dwmw2@infradead.org>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-11 08:57:28 +08:00
Michael D Kinney b26f0cf9ee OvmfPkg: Replace BSD License with BSD+Patent License
https://bugzilla.tianocore.org/show_bug.cgi?id=1373

Replace BSD 2-Clause License with BSD+Patent License.  This change is
based on the following emails:

  https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
  https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html

RFCs with detailed process for the license change:

  V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
  V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
  V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2019-04-09 10:58:19 -07:00
Hao Wu a068102296 OvmfPkg: Add a build flag to select ISA driver stack
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495

This commit will add a static build flag 'USE_LEGACY_ISA_STACK' to select
the ISA driver stack.

If the flag is set to TRUE, the below driver stack will be used:
  PcAtChipsetPkg/IsaAcpiDxe/IsaAcpi.inf
  IntelFrameworkModulePkg/Bus/Isa/IsaBusDxe/IsaBusDxe.inf
  IntelFrameworkModulePkg/Bus/Isa/IsaSerialDxe/IsaSerialDxe.inf
  IntelFrameworkModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2keyboardDxe.inf

If the flag is set to FALSE, the below driver stack will be used:
  OvmfPkg/SioBusDxe/SioBusDxe.inf
  MdeModulePkg/Bus/Pci/PciSioSerialDxe/PciSioSerialDxe.inf
  MdeModulePkg/Bus/Isa/Ps2KeyboardDxe/Ps2KeyboardDxe.inf

The default value is set to FALSE in OVMF DSC files.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>
2019-03-27 13:13:58 +08:00
Hao Wu a5cc178aeb OvmfPkg: Add an Super IO bus driver
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495

There is a plan to remove the IntelFrameworkModulePkg:
https://bugzilla.tianocore.org/show_bug.cgi?id=1605

This patch will a new OVMF Super I/O bus driver which will create the
below child devices:

* COM 1 UART
* COM 2 UART
* PS/2 Keyboard

and installs the Super I/O Protocol on them.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>
2019-03-27 13:13:56 +08:00
Hao Wu e259ad9b64 OvmfPkg: Drop the ISA Floppy device support
REF:https://bugzilla.tianocore.org/show_bug.cgi?id=1495

There is a plan to remove the IntelFrameworkModulePkg:
https://bugzilla.tianocore.org/show_bug.cgi?id=1605

And for driver:
IntelFrameworkModulePkg/Bus/Isa/IsaFloppyDxe

This patch proposes to drop the ISA Floppy device support in OVMF.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Anthony PERARD <anthony.perard@citrix.com>
2019-03-27 13:13:54 +08:00
Laszlo Ersek 77874ceebb OvmfPkg: add library to track boot option loading/starting on the console
Introduce the Platform Boot Manager Print Status Code Library (for short,
PlatformBmPrintScLib) class for catching and printing the LoadImage() /
StartImage() preparations, and return statuses, that are reported by
UefiBootManagerLib.

In the primary library instance, catch only such status codes that
UefiBootManagerLib reports from the same module that contains
PlatformBmPrintScLib. The intent is to establish a reporting-printing
channel within BdsDxe, between UefiBootManagerLib and
PlatformBmPrintScLib. Ignore status codes originating elsewhence, e.g.
from UiApp's copy of UefiBootManagerLib.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Cc: Ray Ni <ray.ni@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1515418
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-25 11:51:22 +01:00
Shenglei Zhang e067816aee OvmfPkg/README: Remove UNIXGCC
Remove UNIXGCC in OvmfPkgIa32.dsc, OvmfPkgIa32X64.dsc
and OvmfPkgX64.dsc.
Remove content related to UNIXGCC in README.
https://bugzilla.tianocore.org/show_bug.cgi?id=1377

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2019-02-14 15:40:26 +08:00
Stefan Berger 3103389043 OvmfPkg: Add TCG2 Configuration menu to the Device Manager menu
This patch adds the TCG2 Configuration menu to the Device Manager
menu. We can apparently reuse the sample Tcg2ConfigDxe from
SecurityPkg/Tcg/Tcg2Config without obvious adverse effects. The
added TCG2 Configuration menu now shows details about the attached
TPM 2.0 and lets one for example configure the active PCR banks
or issue commands, among other things.

The code is added to Ovmf by building with -DTPM2_ENABLE and
-DTPM2_CONFIG_ENABLE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Stefan Berger <stefanb@linux.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Marc-André Lureau <marcandre.lureau@redhat.com>
2019-02-11 13:13:13 +01:00
Ard Biesheuvel 8b3dcd2f9a OvmfPkg: add MmServicesTableLib resolution
The SMM based FTW and variable drivers are going to depend on
MmServicesTableLib after a subsequent patch, so add a resolution
for it to various OvmfPkg .dsc files.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
2019-01-16 17:51:00 +01:00
Star Zeng b7652b7667 OvmfPkg: Remove PcdPeiCoreMaxXXX PCDs' statement
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1405

The codes have been updated to not use PcdPeiCoreMaxFvSupported,
PcdPeiCoreMaxPeimPerFv and PcdPeiCoreMaxPpiSupported, so their
statement in platform DSC could be removed.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-12-19 12:33:32 +08:00
Liming Gao 277a3958d9 OvmfPkg: Don't include TftpDynamicCommand in XCODE5 tool chain
https://bugzilla.tianocore.org/show_bug.cgi?id=1355
XCODE doesn't support HII resource section. TftpDynamicCommand driver depends
on HII resource section. To let OvmfPkg boot to shell on XCODE5 tool chain,
don't include TftpDynamicCommand driver.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-27 11:21:15 +08:00
shenglei 4b888334d2 OvmfPkg: Remove EdkShellBinPkg in FDF
Remove EdkShellBinPkg in OvmfPkgIa32.fdf,
OvmfPkg/OvmfPkgIa32X64.fdf amd OvmfPkg/OvmfPkgX64.fdf.
https://bugzilla.tianocore.org/show_bug.cgi?id=1108

v2: Remove USE_OLD_SHELL in DSC and FDF because it will be
    unnecessary to use it.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Shenglei Zhang <shenglei.zhang@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-19 10:50:15 +08:00
Fu Siyuan d2f1f6423b OvmfPkg: Replace obsoleted network drivers from platform DSC/FDF.
V2:
Add missed library instance for NetworkPkg iSCSI driver.

This patch replaces the MdeModulePkg TCP, PXE and iSCSI driver with those
ones in NetworkPkg. These 3 drivers in MdeModulePkg are not being actively
maintained and will be removed from edk2 master soon.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-11-06 09:07:30 +08:00
Gary Lin b9130c866d OvmfPkg: link Sha384 and Sha512 support into Tcg2Pei and Tcg2Dxe
Sha384 and Sha512 were added to HashInstanceLib recently. To make them
available in Tcg2Pei and Tcg2Dxe, we have to link both libraries.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Marc-André Lureau <marcandre.lureau@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Build-tested-by: Laszlo Ersek <lersek@redhat.com>
2018-08-16 20:32:52 +02:00
Liming Gao 0ed73bcdcd OvmfPkg: Correct ResourcePublicationLib class name in DSC/INF files
ResourcePublicationLib class name is ResourcePublicationLib.
INF and DSC files are updated to use the correct one.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Signed-off-by: Dongao Guo <dongao.guo@intel.com>
[lersek@redhat.com: insert empty line between commit msg body and tags]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-07-24 14:04:11 +02:00
Gerd Hoffmann 1d25ff51af OvmfPkg: add QemuRamfbDxe
Add a driver for the qemu ramfb display device.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Gerd Hoffmann <kraxel@redhat.com>
[lersek@redhat.com: fix INF banner typo]
[lersek@redhat.com: make some local variable definitions more idiomatic]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
2018-06-14 11:56:45 +02:00
Laszlo Ersek e9b2cf7bf0 OvmfPkg: resolve PciCapLib, PciCapPciSegmentLib, PciCapPciIoLib
Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to
their single respective instances. Later patches will use these lib
classes in OvmfPkg drivers.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-05-24 21:21:52 +02:00
Marc-André Lureau b9777bb42e OvmfPkg: add Tcg2PhysicalPresenceLibQemu
Cloned "SecurityPkg/Library/DxeTcg2PhysicalPresenceLib" and:

- removed all the functions that are unreachable from
  Tcg2PhysicalPresenceLibProcessRequest() [called from platform BDS],
  or SubmitRequestToPreOSFunction() and
  ReturnOperationResponseToOsFunction() [called from Tcg2Dxe].

- replaced everything that's related to the
  TCG2_PHYSICAL_PRESENCE*_VARIABLE variables, with direct access to
  the QEMU structures.

This commit is based on initial experimental work from Stefan Berger.
In particular, he wrote most of QEMU PPI support, and designed the
qemu/firmware interaction. Initially, Stefan tried to reuse the
existing SecurityPkg code, but we eventually decided to get rid of the
variables and simplify the ovmf/qemu version.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[lersek@redhat.com: clean up non-idiomatic coding style]
[lersek@redhat.com: null mPpi on invalid PPI address]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22 16:30:44 +02:00
Marc-André Lureau fe280ecbee OvmfPkg: add Tcg2PhysicalPresenceLibNull when !TPM2_ENABLE
This NULL library will let us call
Tcg2PhysicalPresenceLibProcessRequest() unconditionally from
BdsPlatform when building without TPM2_ENABLE.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
[lersek@redhat.com: replace MdeModulePkg.dec w/ MdePkg.dec]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-05-22 16:30:43 +02:00
Laszlo Ersek 6301d2e24a OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe
BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg
in March 2010, in adjacent commits b0f5144676 and efd82c5794. In the
past eight years, no driver or application seems to have materialized that
produced BLOCK_MMIO_PROTOCOL instances. Meanwhile the UEFI spec has
developed the EFI_RAM_DISK_PROTOCOL, which edk2 implements (and OVMF
includes) as RamDiskDxe.

Rather than fixing issues in the unused BlockMmioToBlockIoDxe driver,
remove the driver, together with the BLOCK_MMIO_PROTOCOL definition that
now becomes unused too.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Steven Shi <steven.shi@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=926
Reported-by: Steven Shi <steven.shi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2018-04-10 21:39:40 +02:00
Laszlo Ersek 9c7d0d4992 OvmfPkg/TlsAuthConfigLib: configure trusted CA certs for HTTPS boot
Introduce TlsAuthConfigLib to read the list of trusted CA certificates
from fw_cfg and to store it to EFI_TLS_CA_CERTIFICATE_VARIABLE.

The fw_cfg file is formatted by the "p11-kit" and "update-ca-trust"
utilities on the host side, so that the host settings take effect in guest
HTTPS boot as well. QEMU forwards the file intact to the firmware. The
contents are sanity-checked by NetworkPkg/HttpDxe code that was added in
commit 0fd13678a6.

Link TlsAuthConfigLib via NULL resolution into TlsAuthConfigDxe. This sets
EFI_TLS_CA_CERTIFICATE_VARIABLE in time for both
NetworkPkg/TlsAuthConfigDxe (for possible HII interaction with the user)
and for NetworkPkg/HttpDxe (for the effective TLS configuration).

The file formatted by "p11-kit" can be large. On a RHEL-7 host, the the
Mozilla CA root certificate bundle -- installed with the "ca-certificates"
package -- is processed into a 182KB file. Thus, create
EFI_TLS_CA_CERTIFICATE_VARIABLE as a volatile & boot-time only variable.
Also, in TLS_ENABLE builds, set the cumulative limit for volatile
variables (PcdVariableStoreSize) to 512KB, and the individual limit for
the same (PcdMaxVolatileVariableSize) to 256KB.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-30 21:18:35 +02:00
Laszlo Ersek c95e6d0917 OvmfPkg: annotate "PcdVariableStoreSize := PcdFlashNvStorageVariableSize"
As a continuation of the last patch, clarify in the DSC files that we set
PcdVariableStoreSize to the same value as PcdFlashNvStorageVariableSize
just for convenience; the equality is not a technical requirement.

Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Julien Grall <julien.grall@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
2018-03-30 21:18:35 +02:00
Marc-André Lureau d5a002aba0 OvmfPkg: plug DxeTpm2MeasureBootLib into SecurityStubDxe
The library registers a security management handler, to measure images
that are not measure in PEI phase. For example with the qemu PXE rom:

Loading driver at 0x0003E6C2000 EntryPoint=0x0003E6C9076 8086100e.efi

And the following binary_bios_measurements log entry seems to be
added:

PCR: 2	type: EV_EFI_BOOT_SERVICES_DRIVER     	size: 0x4e	digest: 70a22475e9f18806d2ed9193b48d80d26779d9a4

The following order of operations ensures that 3rd party UEFI modules,
such as PCI option ROMs and other modules possibly loaded from outside
of firmware volumes, are measured into the TPM:

(1) Tcg2Dxe is included in DXEFV, therefore it produces the TCG2
    protocol sometime in the DXE phase (assuming a TPM2 chip is present,
    reported via PcdTpmInstanceGuid).

(2) The DXE core finds that no more drivers are left to dispatch from
    DXEFV, and we enter the BDS phase.

(3) OVMF's PlatformBootManagerLib connects all PCI root bridges
    non-recursively, producing PciIo instances and discovering PCI
    oproms.

(4) The dispatching of images that don't originate from FVs is deferred
    at this point, by
    "MdeModulePkg/Universal/SecurityStubDxe/Defer3rdPartyImageLoad.c".

(5) OVMF's PlatformBootManagerLib signals EndOfDxe.

(6) OVMF's PlatformBootManagerLib calls
    EfiBootManagerDispatchDeferredImages() -- the images deferred in
    step (4) are now dispatched.

(7) Image dispatch invokes the Security / Security2 Arch protocols
    (produced by SecurityStubDxe). In this patch, we hook
    DxeTpm2MeasureBootLib into SecurityStubDxe, therefore image dispatch
    will try to locate the TCG2 protocol, and measure the image into the
    TPM2 chip with the protocol. Because of step (1), the TCG2 protocol
    will always be found and used (assuming a TPM2 chip is present).

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-03-09 18:10:49 +01:00
Marc-André Lureau 0c0a50d6b3 OvmfPkg: include Tcg2Dxe module
This module measures and log the boot environment. It also produces
the Tcg2 protocol, which allows for example to read the log from OS.

The linux kernel doesn't yet read the EFI_TCG2_EVENT_LOG_FORMAT_TCG_2,
which is required for crypto-agile log. In fact, only upcoming 4.16
adds support EFI_TCG2_EVENT_LOG_FORMAT_TCG_1_2:

[    0.000000] efi: EFI v2.70 by EDK II
[    0.000000] efi:  SMBIOS=0x3fa1f000  ACPI=0x3fbb6000  ACPI 2.0=0x3fbb6014  MEMATTR=0x3e7d4318  TPMEventLog=0x3db21018

$ python chipsec_util.py tpm parse_log binary_bios_measurements

[CHIPSEC] Version 1.3.5.dev2
[CHIPSEC] API mode: using OS native API (not using CHIPSEC kernel module)
[CHIPSEC] Executing command 'tpm' with args ['parse_log', '/tmp/binary_bios_measurements']

PCR: 0	type: EV_S_CRTM_VERSION               	size: 0x2	digest: 1489f923c4dca729178b3e3233458550d8dddf29
	+ version:
PCR: 0	type: EV_EFI_PLATFORM_FIRMWARE_BLOB   	size: 0x10	digest: fd39ced7c0d2a61f6830c78c7625f94826b05bcc
	+ base: 0x820000	length: 0xe0000
PCR: 0	type: EV_EFI_PLATFORM_FIRMWARE_BLOB   	size: 0x10	digest: 39ebc6783b72bc1e73c7d5bcfeb5f54a3f105d4c
	+ base: 0x900000	length: 0xa00000
PCR: 7	type: EV_EFI_VARIABLE_DRIVER_CONFIG   	size: 0x35	digest: 57cd4dc19442475aa82743484f3b1caa88e142b8
PCR: 7	type: EV_EFI_VARIABLE_DRIVER_CONFIG   	size: 0x24	digest: 9b1387306ebb7ff8e795e7be77563666bbf4516e
PCR: 7	type: EV_EFI_VARIABLE_DRIVER_CONFIG   	size: 0x26	digest: 9afa86c507419b8570c62167cb9486d9fc809758
PCR: 7	type: EV_EFI_VARIABLE_DRIVER_CONFIG   	size: 0x24	digest: 5bf8faa078d40ffbd03317c93398b01229a0e1e0
PCR: 7	type: EV_EFI_VARIABLE_DRIVER_CONFIG   	size: 0x26	digest: 734424c9fe8fc71716c42096f4b74c88733b175e
PCR: 7	type: EV_SEPARATOR                    	size: 0x4	digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1	type: EV_EFI_VARIABLE_BOOT            	size: 0x3e	digest: 252f8ebb85340290b64f4b06a001742be8e5cab6
PCR: 1	type: EV_EFI_VARIABLE_BOOT            	size: 0x6e	digest: 22a4f6ee9af6dba01d3528deb64b74b582fc182b
PCR: 1	type: EV_EFI_VARIABLE_BOOT            	size: 0x80	digest: b7811d5bf30a7efd4e385c6179fe10d9290bb9e8
PCR: 1	type: EV_EFI_VARIABLE_BOOT            	size: 0x84	digest: 425e502c24fc924e231e0a62327b6b7d1f704573
PCR: 1	type: EV_EFI_VARIABLE_BOOT            	size: 0x9a	digest: 0b5d2c98ac5de6148a4a1490ff9d5df69039f04e
PCR: 1	type: EV_EFI_VARIABLE_BOOT            	size: 0xbd	digest: 20bd5f402271d57a88ea314fe35c1705956b1f74
PCR: 1	type: EV_EFI_VARIABLE_BOOT            	size: 0x88	digest: df5d6605cb8f4366d745a8464cfb26c1efdc305c
PCR: 4	type: EV_EFI_ACTION                   	size: 0x28	digest: cd0fdb4531a6ec41be2753ba042637d6e5f7f256
PCR: 0	type: EV_SEPARATOR                    	size: 0x4	digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 1	type: EV_SEPARATOR                    	size: 0x4	digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 2	type: EV_SEPARATOR                    	size: 0x4	digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 3	type: EV_SEPARATOR                    	size: 0x4	digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 4	type: EV_SEPARATOR                    	size: 0x4	digest: 9069ca78e7450a285173431b3e52c5c25299e473
PCR: 5	type: EV_SEPARATOR                    	size: 0x4	digest: 9069ca78e7450a285173431b3e52c5c25299e473

$ tpm2_pcrlist
sha1 :
  0  : 35bd1786b6909daad610d7598b1d620352d33b8a
  1  : ec0511e860206e0af13c31da2f9e943fb6ca353d
  2  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  3  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  4  : 45a323382bd933f08e7f0e256bc8249e4095b1ec
  5  : d16d7e629fd8d08ca256f9ad3a3a1587c9e6cc1b
  6  : b2a83b0ebf2f8374299a5b2bdfc31ea955ad7236
  7  : 518bd167271fbb64589c61e43d8c0165861431d8
  8  : 0000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000
sha256 :
  0  : 9ae903dbae3357ac00d223660bac19ea5c021499a56201104332ab966631ce2c
  1  : acc611d90245cf04e77b0ca94901f90e7fa54770f0426f53c3049b532243d1b8
  2  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  3  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  4  : 7a94ffe8a7729a566d3d3c577fcb4b6b1e671f31540375f80eae6382ab785e35
  5  : a5ceb755d043f32431d63e39f5161464620a3437280494b5850dc1b47cc074e0
  6  : 3d458cfe55cc03ea1f443f1562beec8df51c75e14a9fcf9a7234a13f198e7969
  7  : 65caf8dd1e0ea7a6347b635d2b379c93b9a1351edc2afc3ecda700e534eb3068
  8  : 0000000000000000000000000000000000000000000000000000000000000000
  9  : 0000000000000000000000000000000000000000000000000000000000000000
  10 : 0000000000000000000000000000000000000000000000000000000000000000
  11 : 0000000000000000000000000000000000000000000000000000000000000000
  12 : 0000000000000000000000000000000000000000000000000000000000000000
  13 : 0000000000000000000000000000000000000000000000000000000000000000
  14 : 0000000000000000000000000000000000000000000000000000000000000000
  15 : 0000000000000000000000000000000000000000000000000000000000000000
  16 : 0000000000000000000000000000000000000000000000000000000000000000
  17 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  18 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  19 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  20 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  21 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  22 : ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff
  23 : 0000000000000000000000000000000000000000000000000000000000000000
sha384 :

The PhysicalPresenceLib is required, it sets some variables, but the
firmware doesn't act on it yet.

Laszlo Ersek explained on the list why Tpm2DeviceLib has to be
resolved differently for DXE_DRIVER modules in general and for
"Tcg2Dxe.inf" specifically:

  * We have a library class called Tpm2DeviceLib -- this is basically the
  set of APIs declared in "SecurityPkg/Include/Library/Tpm2DeviceLib.h".
  Its leading comment says "This library abstract how to access TPM2
  hardware device".

  There are two *sets* of APIs in "Tpm2DeviceLib.h":

  (a) functions that deal with the TPM2 device:
      - Tpm2RequestUseTpm(),
      - Tpm2SubmitCommand()

      This set of APIs is supposed to be used by clients that *consume*
      the TPM2 device abstraction.

  (b) the function Tpm2RegisterTpm2DeviceLib(), which is supposed to be
      used by *providers* of various TPM2 device abstractions.

  * Then, we have two implementations (instances) of the Tpm2DeviceLib class:
  (1) SecurityPkg/Library/Tpm2DeviceLibTcg2/Tpm2DeviceLibTcg2.inf
  (2) SecurityPkg/Library/Tpm2DeviceLibRouter/Tpm2DeviceLibRouterDxe.inf

  (1) The first library instance ("Tpm2DeviceLibTcg2.inf") implements the
  APIs listed under (a), and it does not implement (b) -- see
  EFI_UNSUPPORTED. In other words, this lib instance is strictly meant for
  drivers that *consume* the TPM2 device abstraction. And, the (a) group
  of APIs is implemented by forwarding the requests to the TCG2 protocol.

  The idea here is that all the drivers that consume the TPM2 abstraction
  do not have to be statically linked with a large TPM2 device library
  instance; instead they are only linked (statically) with this "thin"
  library instance, and all the actual work is delegated to whichever
  driver that provides the singleton TCG2 protocol.

  (2) The second library instance ("Tpm2DeviceLibRouterDxe.inf") is meant
  for the driver that offers (produces) the TCG2 protocol. This lib
  instance implements both (a) and (b) API groups.

  * Here's how things fit together:

  (i) The "SecurityPkg/Library/Tpm2DeviceLibDTpm/Tpm2InstanceLibDTpm.inf"
  library instance (which has no lib class) is linked into "Tcg2Dxe.inf"
  via NULL class resolution. This simply means that before the
  "Tcg2Dxe.inf" entry point function is entered, the constructor function
  of "Tpm2InstanceLibDTpm.inf" will be called.

  (ii) This Tpm2InstanceLibDTpmConstructor() function calls API (b), and
  registers its own actual TPM2 command implementation with the
  "Tpm2DeviceLibRouter" library instance (also linked into the Tcg2Dxe
  driver). This provides the back-end for the API set (a).

         TCG2 protocol provider (Tcg2Dxe.inf driver) launches
                      |
                      v
    NULL class: Tpm2InstanceLibDTpm instance construction
                      |
                      v
    Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
           backend registration for API set (a)

  (iii) The Tcg2Dxe driver exposes the TCG2 protocol.

  (iv) A TPM2 consumer calls API set (a) via lib instance (1). Such calls
  land in Tcg2Dxe, via the protocol.

  (v) Tcg2Dxe serves the protocol request by forwarding it to API set (a)
  from lib instance (2).

  (vi) Those functions call the "backend" functions registered by
  Tpm2DeviceLibDTpm in step (ii).

       TPM 2 consumer driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibTcg2 instance
                |
                v
         TCG2 protocol interface
                |
                v
  TCG2 protocol provider: Tcg2Dxe.inf driver
                |
                v
  Tpm2DeviceLib class: Tpm2DeviceLibRouter instance
                |
                v
     NULL class: Tpm2InstanceLibDTpm instance
        (via earlier registration)
                |
                v
       TPM2 chip (actual hardware)

  * So that is the "router" pattern in edk2. Namely,

  - Consumers of an abstraction use a thin library instance.

  - The thin library instance calls a firmware-global (singleton) service,
    i.e. a PPI (in the PEI phase) or protocol (in the DXE phase).

  - The PEIM providing the PPI, or the DXE driver providing the protocol,
    don't themselves implement the actual service either. Instead they
    offer a "registration" service too, and they only connect the incoming
    "consumer" calls to the earlier registered back-end(s).

  - The "registration service", for back-ends to use, may take various
    forms.

    It can be exposed globally to the rest of the firmware, as
    another member function of the PPI / protocol structure. Then backends
    can be provided by separate PEIMs / DXE drivers.

    Or else, the registration service can be exposed as just another
    library API. In this case, the backends are provided as NULL class
    library instances, and a platform  DSC file links them into the PEIM /
    DXE driver via NULL class resolutions. The backend lib instances call
    the registration service in their own respective constructor
    functions.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-03-09 18:10:10 +01:00
Marc-André Lureau 4672a48928 OvmfPkg: include Tcg2Pei module
This module will initialize TPM device, measure reported FVs and BIOS
version. We keep both SHA-1 and SHA-256 for the TCG 1.2 log format
compatibility, but the SHA-256 measurements and TCG 2 log format are
now recommended.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-03-09 18:09:54 +01:00
Marc-André Lureau 6cf1880fb5 OvmfPkg: add customized Tcg2ConfigPei clone
The Tcg2ConfigPei module informs the firmware globally about the TPM
device type, by setting the PcdTpmInstanceGuid PCD to the appropriate
GUID value. The original module under SecurityPkg can perform device
detection, or read a cached value from a non-volatile UEFI variable.

OvmfPkg's clone of the module only performs the TPM2 hardware detection.

This is what the module does:

- Check the QEMU hardware for TPM2 availability only

- If found, set the dynamic PCD "PcdTpmInstanceGuid" to
  &gEfiTpmDeviceInstanceTpm20DtpmGuid. This is what informs the rest of
  the firmware about the TPM type.

- Install the gEfiTpmDeviceSelectedGuid PPI. This action permits the
  PEI_CORE to dispatch the Tcg2Pei module, which consumes the above PCD.
  In effect, the gEfiTpmDeviceSelectedGuid PPI serializes the setting
  and the consumption of the "TPM type" PCD.

- If no TPM2 was found, install gPeiTpmInitializationDonePpiGuid.
  (Normally this is performed by Tcg2Pei, but Tcg2Pei doesn't do it if
  no TPM2 is available. So in that case our Tcg2ConfigPei must do it.)

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Stefan Berger <stefanb@linux.vnet.ibm.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-03-09 18:09:21 +01:00
Marc-André Lureau 5487d002fa OvmfPkg: simplify SecurityStubDxe.inf inclusion
SecurityStubDxe.inf should be included unconditionally.

Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Marc-André Lureau <marcandre.lureau@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-03-09 18:09:10 +01:00
Laszlo Ersek f3f80a57e1 OvmfPkg: drop stale SafeBlockIoLib and SafeOpenProtocolLib resolutions
These are listed under "ShellPkg/Application/Shell/Shell.inf", but they
have been commented out ever since commit 345a0c8fce ("OvmfPkg: Add
support for UEFI shell", 2011-06-26). No such lib classes exist in edk2.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jaben Carsey <jaben.carsey@intel.com>
2018-02-13 13:29:19 +01:00
Michael D Kinney 7fc21c29e8 OvmfPkg: Add SafeIntLib and BmpSupportLib to DSC files
https://bugzilla.tianocore.org/show_bug.cgi?id=800

Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
33bab4031a
ca516b1a61
2b9f111f2e

The BootGraphicsResourceTableDxe module uses the BmpSupportLib
and SafeIntLib to convert a GOP BLT buffer to a BMP graphics image.
Add library mappings for these new library classes.

Cc: Sean Brogan <sean.brogan@microsoft.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Bret Barkelew <Bret.Barkelew@microsoft.com>
2018-02-11 16:06:07 -08:00
Liming Gao 4a64cbda86 OvmfPkg: Don't add -mno-mmx -mno-sse option for XCODE5 tool chain
Ovmf appended option -mno-mmx -mno-sse, but these two options were enabled
in Openssl. The compiler option becomes -mmmx ?msse -mno-mmx -mno-sse. It
trig mac clang compiler hang when compile one source file in openssl.
This issue is found when SECURE_BOOT_ENABLE is TRUE. This may be the compiler
issue. To work around it, don't add these two options for XCODE5 tool chain.

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2018-01-16 23:43:15 +08:00
Ruiyu Ni 984ba6a467 OvmfPkg: Add tftp dynamic command
The TFTP command was converted from a NULL class library instance
to a dynamic shell command in commit 0961002352.
This patch complements commit f9bc2f8763, which only removed the
old library, but didn't add the new dynamic command。

Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Anthony Perard <anthony.perard@citrix.com>
Cc: Julien Grall <julien.grall@linaro.org>
2017-11-29 10:56:13 +08:00
Ruiyu Ni f9bc2f8763 OvmfPkg: Fix build failure due to Tftp library removal
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-11-28 15:23:46 +08:00
Paolo Bonzini c9eb56e5fd OvmfPkg: create a separate PlatformDebugLibIoPort instance for SEC
The next patch will want to add a global variable to
PlatformDebugLibIoPort, but this is not suitable for the SEC
phase, because SEC runs from read-only flash.  The solution is
to have two library instances, one for SEC and another
for all other firmware phases.  This patch adds the "plumbing"
for the SEC library instance, separating the INF files and
moving the constructor to a separate C source file.

Contributed-under: TianoCore Contribution Agreement 1.1
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Jordan Justen (Intel address) <jordan.l.justen@intel.com>
Signed-off-by: Paolo Bonzini <pbonzini@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-11-17 18:35:08 +01:00
Laszlo Ersek 1958124a6c OvmfPkg: fix dynamic default for oprom verification policy PCD without SB
I missed the following, both while reviewing and while testing commit
6041ac65ae ("OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION
when SEV is active", 2017-10-05):

If "-D SECURE_BOOT_ENABLE" is not passed on the "build" command line, then
OVMF has no dynamic default at all for
"PcdOptionRomImageVerificationPolicy". This means that the PcdSet32S()
call added in the subject commit doesn't even compile:

> OvmfPkg/PlatformPei/AmdSev.c: In function 'AmdSevInitialize':
> OvmfPkg/PlatformPei/AmdSev.c:67:3: error: implicit declaration of
> function '_PCD_SET_MODE_32_S_PcdOptionRomImageVerificationPolicy'
> [-Werror=implicit-function-declaration]
>    PcdStatus = PcdSet32S (PcdOptionRomImageVerificationPolicy, 0x4);
>    ^
> cc1: all warnings being treated as errors

Make the current, SB-only, 0x00 dynamic default unconditional.

This is the simplest approach, and it reflects the intent of original
commit 1fea9ddb4e ("OvmfPkg: execute option ROM images regardless of
Secure Boot", 2016-01-07). Without SECURE_BOOT_ENABLE,
"SecurityPkg/Library/DxeImageVerificationLib" is not used anyway, so the
PCD is never read.

This issue was first caught and reported by Gerd Hoffmann
<kraxel@redhat.com>'s Jenkins CI. Later it was also reported in
<https://bugzilla.tianocore.org/show_bug.cgi?id=737>.

Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: 6041ac65ae
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: trim commit message as suggested by Jordan]
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: add reference to TianoCore BZ#737]
2017-10-19 10:41:09 +02:00
Brijesh Singh 6041ac65ae OvmfPkg/PlatformPei: DENY_EXECUTE_ON_SECURITY_VIOLATION when SEV is active
The following commit:

1fea9ddb4e OvmfPkg: execute option ROM images regardless of Secure Boot

sets the OptionRomImageVerificationPolicy to ALWAYS_EXECUTE the expansion
ROMs attached to the emulated PCI devices. A expansion ROM constitute
another channel through which a cloud provider (i.e hypervisor) can
inject a code in guest boot flow to compromise it.

When SEV is enabled, the bios code has been verified by the guest owner
via the SEV guest launch sequence before its executed. When secure boot,
is enabled, lets make sure that we do not allow guest bios to execute a
code which is not signed by the guest owner.

Fixes: https://bugzilla.tianocore.org/show_bug.cgi?id=728
Cc: Chao Zhang <chao.b.zhang@intel.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Tom Lendacky <thomas.lendacky@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-10-17 21:28:27 +02:00
Paulo Alcantara f5566d1530 OvmfPkg: Enable UDF file system support
This patch enables UDF file system support by default.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Paulo Alcantara <pcacjr@zytor.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
2017-09-08 20:42:51 +02:00
Brijesh Singh c6ab9aecb7 OvmfPkg: update PciHostBridgeDxe to use PlatformHasIoMmuLib
This patch enables PciHostBridgeDxe driver to use Platform IoMMU detection
library to ensure that PciHostBridgeDxe is run after platform IoMmuDxe
driver has checked whether platform need to install IOMMU protocol provider.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Suggested-by: Laszlo Ersek <lersek@redhat.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10 21:17:28 -07:00
Brijesh Singh fee47a261c OvmfPkg/QemuFwCfgLib: Provide Pei and Dxe specific library
Current QemuFwCfgLib.inf is used in both Pei and Dxe phases. Add Pei
and Dxe inf file to provide a seperate QemuFwCfgLib instances for Pei
and Dxe phases.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10 21:17:28 -07:00
Brijesh Singh f9d129e68a OvmfPkg: Add IoMmuDxe driver
The IOMMU protocol driver provides capabilities to set a DMA access
attribute and methods to allocate, free, map and unmap the DMA memory
for the PCI Bus devices.

Due to security reasons all DMA operations inside the SEV guest must
be performed on shared (i.e unencrypted) pages. The IOMMU protocol
driver for the SEV guest uses a bounce buffer to map guest DMA buffer
to shared pages inorder to provide the support for DMA operations inside
SEV guest.

IoMmuDxe driver looks for SEV capabilities, if present then it installs
the real IOMMU protocol otherwise it installs placeholder protocol.
Currently, PciHostBridgeDxe and QemuFWCfgLib need to know the existance
of IOMMU protocol. The modules needing to know the existance of IOMMU
support should add

  gEdkiiIoMmuProtocolGuid OR gIoMmuAbsentProtocolGuid

in their depex to ensure that platform IOMMU detection has been performed.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Leo Duran <leo.duran@amd.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Suggested-by: Jiewen Yao <jiewen.yao@intel.com>
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10 21:17:28 -07:00
Brijesh Singh 13b5d743c8 OvmfPkg/PlatformPei: Set memory encryption PCD when SEV is enabled
Secure Encrypted Virtualization (SEV) guest VMs have the concept of
private and shared memory. Private memory is encrypted with the
guest-specific key, while shared memory may be encrypted with hypervisor
key.  Certain types of memory (namely instruction pages and guest page
tables) are always treated as private memory by the hardware.
For data memory, SEV guest VMs can choose which pages they would like
to be private. The choice is done using the standard CPU page tables
using the C-bit. When building the initial page table we mark all the
memory as private.

The patch sets the memory encryption PCD. The PCD is consumed by the
following edk2 modules, which manipulate page tables:

- PEI phase modules: CapsulePei, DxeIplPeim, S3Resume2Pei.

CapsulePei is not used by OVMF. DxeIplPeim consumes the PCD at the
end of the PEI phase, when it builds the initial page tables for the
DXE core / DXE phase. S3Resume2Pei does not consume the PCD in its
entry point function, only when DxeIplPeim branches to the S3 resume
path at the end of the PEI phase, and calls S3Resume2Pei's
EFI_PEI_S3_RESUME2_PPI.S3RestoreConfig2() member function.

Therefore it is safe to set the PCD for these modules in PlatformPei.

- DXE phase modules: BootScriptExecutorDxe, CpuDxe, PiSmmCpuDxeSmm.

They are all dispatched after the PEI phase, so setting the PCD for
them in PlatformPei is safe. (BootScriptExecutorDxe is launched "for
real" in the PEI phase during S3 resume, but it caches the PCD into a
static variable when its entry point is originally invoked in DXE.)

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10 21:17:27 -07:00
Brijesh Singh a1f2261425 OvmfPkg/BaseMemcryptSevLib: Add SEV helper library
Add Secure Encrypted Virtualization (SEV) helper library.
The library provides the routines to:
-  set or clear memory encryption bit for a given memory region.
-  query whether SEV is enabled.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10 21:17:27 -07:00
Brijesh Singh 97353a9c91 OvmfPkg: Update dsc to use IoLib from BaseIoLibIntrinsicSev.inf
When SEV is enabled then we must unroll the rep String I/O instructions.

The patch updates dsc file to use SEV version of IoLib inf. The main
difference between BaseIoLibIntrinsic.inf and BaseIoLibIntrinsicSev.inf
is, SEV version checks if its running under SEV enabled guest, If so
then it unroll the String I/O (REP INS/OUTS) otherwise fallbacks to
rep ins/outs.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Brijesh Singh <brijesh.singh@amd.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-10 21:17:27 -07:00
Laszlo Ersek 966dbaf400 OvmfPkg: make PcdQ35TsegMbytes dynamic
We can now make PcdQ35TsegMbytes dynamic, in preparation for the extended
TSEG size feature. At the moment we only move the declaration in
OvmfPkg.dec from [PcdsFixedAtBuild] to [PcdsDynamic, PcdsDynamicEx], and
provide the dynamic defaults (with the same value, 8) in the DSC files if
SMM_REQUIRE is TRUE.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-07-05 22:26:19 +02:00
Laszlo Ersek 1c47fcd465 OvmfPkg: make the 4MB flash size the default (again)
Xen gained support for the 4MB flash image in Xen commit 0d6968635ce5
("hvmloader: avoid tests when they would clobber used memory",
2017-05-19), which is part of Xen 4.9.0-rc6.

The previously default 2MB can be explicitly selected with

  -D FD_SIZE_2MB

or

  -D FD_SIZE_IN_KB=2048

Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
(cherry picked from commit bba8dfbec3)
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
[lersek@redhat.com: reference Xen commit in commit message]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-05-23 17:46:11 +02:00
Michael Kinney 01e9597540 OvmfPkg: Add XCODE5 statements to fix build break
https://bugzilla.tianocore.org/show_bug.cgi?id=559

The XCODE5 tool chain has a FAMILY of GCC.  The
GCC statements in the [BuildOptions] section add
flags that are not compatible with XCODE5.  Add
empty XCODE5 statements in [BuildOptions] sections
to prevent the use of the GCC flags in XCODE5
builds.

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-05-19 14:22:13 -07:00
Laszlo Ersek 639c7dd86d OvmfPkg: resolve PcdLib for PEIMs to PeiPcdLib by default
In the previous patch we had to add two explicit Null resolutions, but
here we can remove five PeiPcdLib ones, after setting the default to it.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 10:13:06 +02:00
Laszlo Ersek fbce1fe983 OvmfPkg: resolve PcdLib for all PEIMs individually
Currently the default (module type independent) PcdLib resolution is to
BasePcdLibNull.inf, which is inherited by all PEIMs. In the next patch,
we'll flip the PEIM default resolution to PeiPcdLib.inf, but in order to
keep that patch both correct and simple to review, we should spell out the
Null resolution for those two PEIMs (ReportStatusCodeRouterPei and
StatusCodeHandlerPei) that are now the only ones that don't specify an
explicit resolution.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 10:13:03 +02:00
Laszlo Ersek 5e167d7e78 OvmfPkg/PlatformPei: don't allocate reserved mem varstore if SMM_REQUIRE
For the emulated variable store, PlatformPei allocates reserved memory (as
early as possible, so that the address remains the same during reboot),
and PcdEmuVariableNvStoreReserved carries the address to
EmuVariableFvbRuntimeDxe.

However, EmuVariableFvbRuntimeDxe is excluded from the SMM_REQUIRE build,
and then noone consumes PcdEmuVariableNvStoreReserved. Don't waste
reserved memory whenever that's the case.

(Even a dynamic default for PcdEmuVariableNvStoreReserved would be
unnecessary; but that way the PcdSet64S() call in the
ReserveEmuVariableNvStore() function doesn't compile.)

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 10:13:01 +02:00
Laszlo Ersek 62f43f7c19 OvmfPkg: sync PcdVariableStoreSize with PcdFlashNvStorageVariableSize
"MdeModulePkg/MdeModulePkg.dec" declares PcdVariableStoreSize like this:

> The size of volatile buffer. This buffer is used to store VOLATILE
> attribute variables.

There is no inherent reason why the size of the volatile variable store
should match the same of the non-volatile variable store. Indeed flash
variables in the 4MB build work fine without this equality.

However, OvmfPkg/EmuVariableFvbRuntimeDxe uses PcdVariableStoreSize to
initialize the non-volatile VARIABLE_STORE_HEADER too. (Presumably based
on the fact that ultimately that storage will not be permanent.) When
using EmuVariableFvbRuntimeDxe in the 4MB build, the mismatch between the
two mentioned PCDs (which is apparent through EmuVariableFvbRuntimeDxe's
VARIABLE_STORE_HEADER) triggers an assertion in the variable driver:

> ASSERT MdeModulePkg/Universal/Variable/RuntimeDxe/Variable.c(3772):
> mNvVariableCache->Size == VariableStoreLength

Bringing PcdVariableStoreSize in sync with PcdFlashNvStorageVariableSize
fixes this. It also happens to ensure a volatile store size in the 4MB
build that equals the non-volatile store size, which likely doesn't hurt
for symmetry.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Fixes: b24fca0575
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 10:12:58 +02:00
Laszlo Ersek 5c27723204 OvmfPkg: remove gUefiOvmfPkgTokenSpaceGuid.PcdSecureBootEnable
This PCD is no longer used.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-18 10:12:52 +02:00
Laszlo Ersek 6e49d01cfb Revert "OvmfPkg: make the 4MB flash size the default"
This reverts commit bba8dfbec3.

The 264KB size introduced for the NV spare area in commit b24fca0575
("OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK",
2017-04-29) breaks the "-bios" (emulated varstore) use case. Until we sort
that out, revert the default build to the 2MB image.

Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-05 18:01:14 +02:00
Laszlo Ersek bba8dfbec3 OvmfPkg: make the 4MB flash size the default
The previously default 2MB can be explicitly selected with

  -D FD_SIZE_2MB

or

  -D FD_SIZE_IN_KB=2048

Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Suggested-by: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-05 00:56:24 +02:00
Laszlo Ersek 88a30bbc0a OvmfPkg: raise max variable size (auth & non-auth) to 33KB for FD_SIZE_4MB
The "ConfirmSetOfLargeVariable" test case of the Secure Boot Logo Test
("Microsoft.UefiSecureBootLogo.Tests") suite in the Microsoft Hardware
Certification Kit sets a 32 KB large non-authenticated variable.

In the FD_SIZE_4MB build, our live varstore is now 256 KB big, so we can
accommodate this. Set both PcdMaxVariableSize and PcdMaxAuthVariableSize
to 0x8400 -- beyond DataSize=0x8000 from the HCK test, we need some room
for the variable name and attributes as well.

Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-05 00:56:21 +02:00
Laszlo Ersek b24fca0575 OvmfPkg: introduce 4MB flash image (mainly) for Windows HCK
The "Confirm64KilobytesOfUnauthenticatedVariableStorage" test case of the
Secure Boot Logo Test ("Microsoft.UefiSecureBootLogo.Tests") suite in the
Microsoft Hardware Certification Kit expects to be able to populate the
variable store up to roughly 64 KB, with a series of 1 KB sized,
unauthenticated variables. OVMF's current live varstore area is too small
for this: 56 KB.

Introduce the FD_SIZE_4MB build macro (equivalently, FD_SIZE_IN_KB=4096),
which

- enlarges the full flash image to 4MB -- QEMU supports up to 8MB, see
  FLASH_MAP_BASE_MIN in "hw/i386/pc_sysfw.c" --,

- inside that, grows the varstore area / pflash chip to 528 KB, and within
  it, the live area from 56 KB to 256 KB.

Importantly, a firmware binary built with -D FD_SIZE_4MB will *not* be
compatible with a variable store that originates from a variable store
template built *without* -D FD_SIZE_4MB. This is the reason for the large
increase, as every such change breaks compatibility between a new firmware
binary and old varstore files.

Enlarging the varstore does not impact the performance of normal
operations, as we keep the varstore block size 4KB. The performance of
reclaim is affected, but that is expected (since reclaim has to rework the
full live area). And, reclaim occurs proportionally less frequently.

While at it, the FVMAIN_COMPACT volume (with the compressed FFS file in
it) is also enlarged significantly, so that we have plenty of room for
future DXEFV (and perhaps PEIFV) increments -- DXEFV has been growing
steadily, and that increase shows through compression too. Right now the
PEIFV and DXEFV volumes need no resizing.

Here's a summary:

  Description                Compression type                Size [KB]
  -------------------------  -----------------  ----------------------
  Non-volatile data storage  open-coded binary    128 ->   528 ( +400)
                               data
    Variable store                                 56 ->   256 ( +200)
    Event log                                       4 ->     4 (   +0)
    Working block                                   4 ->     4 (   +0)
    Spare area                                     64 ->   264 ( +200)

  FVMAIN_COMPACT             uncompressed        1712 ->  3360 (+1648)
    FV FFS file              LZMA compressed
      PEIFV                  uncompressed         896 ->   896 (   +0)
        individual PEI       uncompressed
          modules
      DXEFV                  uncompressed       10240 -> 10240 (   +0)
        individual DXE       uncompressed
          modules

  SECFV                      uncompressed         208 ->   208 (   +0)
    SEC driver
    reset vector code

For now, the 2MB flash image remains the default.

Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-05 00:56:18 +02:00
Laszlo Ersek 210270730c OvmfPkg: introduce the FD_SIZE_IN_KB macro / build flag
FD_SIZE_xMB defines have existed for flash size selection. They can be
passed as "-D FD_SIZE_xMB" on the command line. Passing multiple of them
at the same time has never been supported; earlier settings on the command
line cannot be overridden.

Introduce the integer valued FD_SIZE_IN_KB macro, which provides the
following improvements:

- several instances of it are permitted on the command line, with the last
  one taking effect,

- conditional statements in the DSC and FDF files need only check a single
  macro, and multiple values can be checked in a single !if with the ||
  operator,

- nested !ifdef / !else ladders can be replaced with flat equality tests,

- in the future, flash sizes can be expressed with a finer than MB
  granularity, if necessary.

For now, we're going to preserve the FD_SIZE_xMB defines as convenience
wrappers for FD_SIZE_IN_KB.

FD_SIZE_IN_KB is being added to the DSC files because this way we can
depend on it in both the DSC and FDF files.

Cc: Gary Ching-Pang Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-05-05 00:55:40 +02:00
Laszlo Ersek b7f2e82c03 OvmfPkg: resolve QemuFwCfgS3Lib
QemuFwCfgS3Enabled() in "OvmfPkg/Library/QemuFwCfgLib/QemuFwCfgLib.c"
queries the "etc/system-states" fw_cfg file.

The same implementation is now available factored-out in
"OvmfPkg/Library/QemuFwCfgS3Lib/QemuFwCfgS3PeiDxe.c". It is available to
PEIMs through the PeiQemuFwCfgS3LibFwCfg instance, and to DXE_DRIVER and
DXE_RUNTIME_DRIVER modules through the DxeQemuFwCfgS3LibFwCfg instance.

Resolve QemuFwCfgS3Lib accordingly.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=394
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-03-14 21:49:14 +01:00
Laszlo Ersek df453e1b7c OvmfPkg: exclude libssl functionality from OpensslLib if TLS_ENABLE=FALSE
The OpensslLibCrypto library instance (which does not contain libssl
functions) is sufficient for the Secure Boot feature.

Ease security analysis by excluding libssl functionality from the
OpensslLib instance we use with TLS_ENABLE=FALSE.

Cc: Gary Lin <glin@suse.com>
Cc: Jordan Justen <jordan.l.justen@intel.com>
Cc: Tomas Hoger <thoger@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Gary Lin <glin@suse.com>
2017-02-25 14:56:53 +01:00
Laszlo Ersek 22d7be69c4 OvmfPkg: dynamic defaults for PcdCpuSmmApSyncTimeout, PcdCpuSmmSyncMode
Move the platform-specific default values for these PCDs from the
[PcdsFixedAtBuild] / [PcdsFixedAtBuild.X64] sections to the
[PcdsDynamicDefault] section.

Cc: Jordan Justen <jordan.l.justen@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=230
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jordan Justen <jordan.l.justen@intel.com>
2017-02-07 12:26:50 +01:00
Jiaxin Wu 4b2fb7986d OvmfPkg: Allow HTTP connections if HTTP Boot enabled
v2
* Move the setting above the "!ifndef $(USE_OLD_SHELL)" part.
* Un-indent the setting to column zero.
(Comments from Laszlo)

Overwrite the value of PcdAllowHttpConnections to allow HTTP
connections if HTTP Boot enabled (-D HTTP_BOOT_ENABLE).

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Ye Ting <ting.ye@intel.com>
Cc: Fu Siyuan <siyuan.fu@intel.com>
Cc: Kinney Michael D <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Ye Ting <ting.ye@intel.com>
Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Reviewed-by: Gary Lin <glin@suse.com>
Tested-by: Gary Lin <glin@suse.com>
2017-01-23 10:27:51 +08:00
Gary Lin 315d9d08fd OvmfPkg: pull in TLS modules with -D TLS_ENABLE (also enabling HTTPS)
This commit introduces a new build option, TLS_ENABLE, to pull in the
TLS-related modules. If HTTP_BOOT_ENABLE and TLS_ENABLE are enabled at
the same time, the HTTP driver locates the TLS protocols automatically
and thus HTTPS is enabled.

To build OVMF with HTTP Boot:

$ ./build.sh -D HTTP_BOOT_ENABLE

To build OVMF with HTTPS Boot:

$ ./build.sh -D HTTP_BOOT_ENABLE -D TLS_ENABLE

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Long Qin <qin.long@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
2017-01-17 10:26:58 +01:00
Gary Lin 32e22f20c9 OvmfPkg: correct the IScsiDxe module included for the IPv6 stack
Always use IScsiDxe from NetworkPkg when IPv6 is enabled since it provides
the complete ISCSI support.

NOTE: This makes OpenSSL a hard requirement when NETWORK_IP6_ENABLE is
      true.

(Based on Jiaxin's suggestion)

Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Justen Jordan L <jordan.l.justen@intel.com>
Cc: Wu Jiaxin <jiaxin.wu@intel.com>
Cc: Long Qin <qin.long@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Gary Lin <glin@suse.com>
Reviewed-by: Wu Jiaxin <jiaxin.wu@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
[lersek@redhat.com: update subject line]
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
2017-01-17 10:25:25 +01:00