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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
(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>
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
Mostly, this is only necessary for devices that the CSM might have
native support for, such as VirtIO and NVMe; PciBusDxe will already
degrade devices to 32-bit if they have an OpROM.
However, there doesn't seem to be a generic way of requesting PciBusDxe
to downgrade specific devices.
There's IncompatiblePciDeviceSupportProtocol but that doesn't provide
the PCI class information or a handle to the device itself, so there's
no simple way to just match on all NVMe devices, for example.
Just leave gUefiOvmfPkgTokenSpaceGuid.PcdPciMmio64Size set to zero for
CSM builds, until/unless that can be fixed.
Signed-off-by: David Woodhouse <dwmw2@infradead.org>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20190626113742.819933-5-dwmw2@infradead.org>
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>
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>
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>
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>
(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>
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>
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>
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]
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
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>
Laszlo Ersek
Ard Biesheuvel
Liming Gao
Michael Kubacki
Peter Jones
Anthony PERARD
Imran Desai
Gary Lin
David Woodhouse
Hao A Wu
Fu Siyuan
Zhang, Shenglei
Michael D Kinney
Stefan Berger
Star Zeng
Gerd Hoffmann
Marc-André Lureau