Laszlo Ersek [Sat, 10 Mar 2018 22:26:12 +0000 (23:26 +0100)]
OvmfPkg/QemuVideoDxe: list "Qemu.h" in the INF file
Among many other things, "Qemu.h" declares the
QemuVideoGraphicsOutputConstructor() and
QemuVideoGraphicsOutputDestructor() functions, which are defined in
"Gop.c", and called from "Driver.c".
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Jordan Justen <jordan.l.justen@intel.com> Cc: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.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: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 22:14:30 +0000 (23:14 +0100)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "QemuFlash.h" in INF files
Among other things, the header file declares functions that are called
from the FVB protocol member functions in "FwBlockService.c", and defined
in "QemuFlash.c".
Both C files are listed in both "FvbServicesSmm.inf" and
"FvbServicesRuntimeDxe.inf", thus add the header file to both INF files as
well.
Laszlo Ersek [Sat, 10 Mar 2018 22:02:32 +0000 (23:02 +0100)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: list "FwBlockService.h" in INFs
Among other things, the header file provides (extern) declarations for the
EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL member functions that are defined in
"FwBlockService.c". This way "mFvbDeviceTemplate.FwVolBlockInstance" can
be initialized near the top of "FwBlockService.c", ahead of the member
function definitions.
"FwBlockService.c" is linked into both the DXE_SMM_DRIVER and the
DXE_RUNTIME_DRIVER builds of this module, thus list the header file in
both INF files.
Laszlo Ersek [Sat, 10 Mar 2018 21:06:34 +0000 (22:06 +0100)]
OvmfPkg/PlatformDxe: list "PlatformConfig.h" in the INF file
The header file declares the PlatformConfigSave() and PlatformConfigLoad()
functions (and defines related types and macros). The functions are
defined in "PlatformConfig.c" and called from "Platform.c".
Laszlo Ersek [Sat, 10 Mar 2018 21:06:34 +0000 (22:06 +0100)]
OvmfPkg/PlatformDxe: list "Platform.h" in the INF file
The header file defines HII-related macros and types that are shared
between the form description in "PlatformForms.vfr" and the HII driver
logic "Platform.c".
Laszlo Ersek [Sat, 10 Mar 2018 20:58:44 +0000 (21:58 +0100)]
OvmfPkg/VirtioMmioDeviceLib: improve style of mMmioDeviceProtocolTemplate
In edk2, we spell "static" "STATIC", plus objects with static storage
duration (esp. protocol templates) should be const-qualified (spelled
"CONST") whenever possible.
Laszlo Ersek [Sat, 10 Mar 2018 20:51:48 +0000 (21:51 +0100)]
OvmfPkg/VirtioMmioDeviceLib: list "VirtioMmioDevice.h" in the INF file
Among other things, the header file declares the functions that implement
the VIRTIO_DEVICE_PROTOCOL members over virtio-mmio. The functions are
defined in "VirtioMmioDeviceFunctions.c", and referenced in the
initialization of "mMmioDeviceProtocolTemplate", in "VirtioMmioDevice.c".
Laszlo Ersek [Sat, 10 Mar 2018 20:41:36 +0000 (21:41 +0100)]
OvmfPkg/QemuBootOrderLib: list "ExtraRootBusMap.h" in the INF file
The header file declares the CreateExtraRootBusMap(),
DestroyExtraRootBusMap(), and MapRootBusPosToBusNr() functions. They are
defined in "ExtraRootBusMap.c", and called from "QemuBootOrderLib.c".
Laszlo Ersek [Sat, 10 Mar 2018 20:14:06 +0000 (21:14 +0100)]
OvmfPkg/PlatformDebugLibIoPort: list "DebugLibDetect.h" in the INF files
Among other things, "DebugLibDetect.h" declares the
PlatformDebugLibIoPortFound() function. The function is called from
"DebugLib.c", which is included in both library instances. The function is
defined separately per library instance, in "DebugLibDetectRom.c" and
"DebugLibDetect.c", respectively.
Laszlo Ersek [Sat, 10 Mar 2018 19:49:56 +0000 (20:49 +0100)]
OvmfPkg/LockBoxLib: list "LockBoxLib.h" in the INF files
Among other things, the header file declares the AllocateAcpiNvsPool()
function. This function is called from the "LockBoxLib.c" source file (in
the implementation of the SaveLockBox() library API), which is built into
both library instances. AllocateAcpiNvsPool() is implemented separately
per library instance, in "LockBoxBase.c" and "LockBoxDxe.c", respectively.
(In the LockBoxBaseLib instance, the AllocateAcpiNvsPool() function is
never expected to be called -- the public SaveLockBox() API should never
be called before the DXE phase --, we just have to provide a stub for
linking purposes.)
Laszlo Ersek [Sat, 10 Mar 2018 19:43:36 +0000 (20:43 +0100)]
OvmfPkg/LoadLinuxLib: list "LoadLinuxLib.h" in the INF file
The header file declares the InitLinuxDescriptorTables() and
SetLinuxDescriptorTables() functions, which are called from "Linux.c" and
implemented in "LinuxGdt.c".
The header file also declares the JumpToKernel() and JumpToUefiKernel()
functions, which are similarly called from "Linux.c". They are implemented
(dependent on architecture) in "Ia32/JumpToKernel.nasm" and
"X64/JumpToKernel.nasm".
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/BaseMemEncryptSevLib: list "X64/VirtualMemory.h" in the INF file
Among other things, the header file declares the
InternalMemEncryptSevSetMemoryDecrypted() and
InternalMemEncryptSevSetMemoryEncrypted() functions. The functions are
called from "X64/MemEncryptSevLib.c", and defined in
"X64/VirtualMemory.c".
Laszlo Ersek [Sat, 10 Mar 2018 19:20:14 +0000 (20:20 +0100)]
OvmfPkg/AcpiTimerLib: list "AcpiTimerLib.h" in the INF files
The header file declares the InternalAcpiGetTimerTick() function. The
function is called from "AcpiTimerLib.c", which is built into all three
library instances. The function is defined individually per library
instance, in "BaseRomAcpiTimerLib.c", "BaseAcpiTimerLib.c", and
"DxeAcpiTimerLib.c" (enumerated in increasing firmware phase order).
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/EmuVariableFvbRuntimeDxe: list "Fvb.h" in the INF file
Among other things, the header file provides (extern) declarations for the
EFI_FIRMWARE_VOLUME_BLOCK_PROTOCOL member functions that are defined in
"Fvb.c". This way "mEmuVarsFvb.FwVolBlockInstance" can be initialized near
the top of "Fvb.c", ahead of the member function definitions.
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> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.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: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyRegion.h" in the INF file
Among other things, the header file provides (extern) declarations for the
EFI_LEGACY_REGION2_PROTOCOL member functions that are defined in
"LegacyRegion.c". This way "mLegacyRegion2" can be initialized near the
top of "LegacyRegion.c", ahead of the member function definitions.
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "LegacyInterrupt.h" in the INF file
Among other things, the header file provides (extern) declarations for the
EFI_LEGACY_INTERRUPT_PROTOCOL member functions that are defined in
"LegacyInterrupt.c". This way "mLegacyInterrupt" can be initialized near
the top of "LegacyInterrupt.c", ahead of the member function definitions.
Laszlo Ersek [Sat, 10 Mar 2018 18:49:52 +0000 (19:49 +0100)]
OvmfPkg/CsmSupportLib: list "CsmSupportLib.h" in the INF file
The header file declares the functions LegacyRegionInit(),
LegacyInterruptInstall() and LegacyBiosPlatformInstall(). They are defined
in "LegacyRegion.c", "LegacyInterrupt.c", and "LegacyPlatform.c",
respectively, and are all called from CsmSupportLibConstructor() in
"CsmSupportLib.c".
Laszlo Ersek [Sat, 10 Mar 2018 18:42:15 +0000 (19:42 +0100)]
OvmfPkg/BlockMmioToBlockIoDxe: list "BlockIo.h" in the INF file
Among other things, the header file declares the
"gBlockMmioToBlockIoComponentName" and "gBlockMmioToBlockIoComponentName2"
protocol instance structures. They are defined and initialized in
"ComponentName.c" and installed in "BlockIo.c".
Laszlo Ersek [Sat, 10 Mar 2018 18:16:02 +0000 (19:16 +0100)]
OvmfPkg/AcpiPlatformDxe: list "QemuLoader.h" in the INF files
"QemuLoader.h" defines the command structures of QEMU's ACPI
linker/loader. The client code is in "QemuFwCfgAcpi.c", which is part of
both builds of this driver.
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: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.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: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 17:26:36 +0000 (18:26 +0100)]
OvmfPkg/AcpiPlatformDxe: don't #include "QemuLoader.h" in "Qemu.c"
We added initial support for QEMU's ACPI linker/loader in commit a618eaa1f45d ("OvmfPkg: AcpiPlatformDxe: don't rely on unstable QEMU
interface", 2014-06-19). This commit defined the command structures in the
new file "QemuLoader.h", and #included the header in the preexistent
"Qemu.c" file, where the initial command script processing loop was being
implemented.
In commit 14b0faadfc87 ("OvmfPkg/AcpiPlatformDxe: Split QEMU fw-cfg into a
new file", 2015-02-02), we extracted the -- by then, more advanced --
linker/loader script processing from "Qemu.c" to "QemuFwCfgAcpi.c".
"Qemu.c" was going to need "QemuLoader.h" no longer, but we forgot to make
the #include directive unique to the new "QemuFwCfgAcpi.c" file. Do it
now.
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: Phil Dennis-Jordan <phil@philjordan.eu>
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: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 17:13:18 +0000 (18:13 +0100)]
OvmfPkg/AcpiPlatformDxe: list "AcpiPlatform.h" in the INF files
Among other things, the header file declares InstallAcpiTables(). This
function is called from AcpiPlatformEntryPoint() -- the entry point of
both INF files, defined in the common "EntryPoint.c" file --, and it is
defined (dependent on INF file) in "AcpiPlatform.c" or
"QemuFwCfgAcpiPlatform.c".
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: Phil Dennis-Jordan <phil@philjordan.eu> Suggested-by: Michael Kinney <michael.d.kinney@intel.com>
Ref: http://mid.mail-archive.com/E92EE9817A31E24EB0585FDF735412F56327F7D3@ORSMSX113.amr.corp.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: Jordan Justen <jordan.l.justen@intel.com>
Laszlo Ersek [Sat, 10 Mar 2018 16:54:24 +0000 (17:54 +0100)]
ArmVirtPkg/ArmVirtPrePiUniCoreRelocatable: list "PrePi.h" in INF file
Among other things, the header file declares the ArchInitialize()
function, which is called from "PrePi.c", and implemented (dependent on
architecture) in "AArch64/ArchPrePi.c" and "Arm/ArchPrePi.c".
Jiaxin Wu [Mon, 12 Mar 2018 00:50:12 +0000 (08:50 +0800)]
NetworkPkg/IScsiDxe: Fix the ISCSI connection failure in certain case.
The ISCSI connection will fail for the first time if the target info is
retrieved from DHCP and expressed as URI format. The issue is caused by
the missing DNS protocol dependency check during the driver support
function.
This patch is to fix the above issue.
Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com>
Jiaxin Wu [Mon, 12 Mar 2018 00:50:41 +0000 (08:50 +0800)]
MdeModulePkg/Mtftp4Dxe: Fix the incorrect return status.
The incorrect return status was caused by the commit of 39b0867d, which
was to resolve the token status error that does not compliance with spec
definition, but it results the protocol status not compliance with spec
definition.
This patch is to resolve above issue.
Cc: Wang Fan <fan.wang@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Ye Ting <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Jiaxin Wu <jiaxin.wu@intel.com> Reviewed-by: Fu Siyuan <siyuan.fu@intel.com> Reviewed-by: Wang, Fan <fan.wang@intel.com>
Brijesh Singh [Fri, 9 Mar 2018 16:06:03 +0000 (10:06 -0600)]
OvmfPkg/QemuFlashFvbServicesRuntimeDxe: Clear C-bit when SEV is active
Commit:24e4ad7 (OvmfPkg: Add AmdSevDxe driver) added a driver which runs
early in DXE phase and clears the C-bit from NonExistent entry -- which
is later split and accommodate the flash MMIO. When SMM is enabled, we
build two sets of page tables; first page table is used when executing
code in non SMM mode (SMM-less-pgtable) and second page table is used
when we are executing code in SMM mode (SMM-pgtable).
During boot time, AmdSevDxe driver clears the C-bit from the
SMM-less-pgtable. But when SMM is enabled, Qemu Flash services are used
from SMM mode.
In this patch we explicitly clear the C-bit from Qemu flash MMIO range
before we probe the flash. When OVMF is built with SMM_REQUIRE then
call to initialize the flash services happen after the SMM-pgtable is
created and processor has served the first SMI. At this time we will
have access to the SMM-pgtable.
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".
(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).
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
[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']
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.
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.
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.)
SecurityPkg: also clear HashInterfaceHob.SupportedHashMask
Commit 4cc2b63bd829426b05bad0d8952f1855a10d6ed7 fixed an out of bounds
ZeroMem() call. However, as Laszlo Ersek pointed out, the intent was
to clear all but the Identifier (to revert the effect of
RegisterHashInterfaceLib()). For that, it should clear the
SupportedHashMask too.
Star Zeng [Sun, 11 Feb 2018 03:00:44 +0000 (11:00 +0800)]
SecurityPkg OpalPassword: Add solution without SMM device code
After IOMMU is enabled in S3, original solution with SMM device
code (OpalPasswordSmm) to unlock OPAL device for S3 will not work
as the DMA operation will be aborted without granted DMA buffer.
Instead, this solution is to add OpalPasswordPei to eliminate
SMM device code, and OPAL setup UI produced by OpalPasswordDxe
will be updated to send requests (set password, update password,
and etc), and then the requests will be processed in next boot
before SmmReadyToLock, password and device info will be saved to
lock box used by OpalPasswordPei to unlock OPAL device for S3.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Star Zeng [Sun, 11 Feb 2018 02:01:21 +0000 (10:01 +0800)]
MdeModulePkg LockBoxLib: Support LOCK_BOX_ATTRIBUTE_RESTORE_IN_S3_ONLY
With this flag, the LockBox can be restored in S3 resume only.
The LockBox can not be restored after SmmReadyToLock in normal boot
and after EndOfS3Resume in S3 resume.
It can not be set together with LOCK_BOX_ATTRIBUTE_RESTORE_IN_PLACE.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Jian J Wang [Fri, 2 Mar 2018 02:46:05 +0000 (10:46 +0800)]
UefiCpuPkg/MpInitLib: put mReservedApLoopFunc in executable memory
if PcdDxeNxMemoryProtectionPolicy is enabled for EfiReservedMemoryType
of memory, #PF will be triggered for each APs after ExitBootServices
in SCRT test. The root cause is that AP wakeup code executed at that
time is stored in memory of type EfiReservedMemoryType (referenced by
global mReservedApLoopFunc), which is marked as non-executable.
This patch fixes this issue by setting memory of mReservedApLoopFunc to
be executable immediately after allocation.
Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Jian J Wang [Wed, 7 Mar 2018 03:26:32 +0000 (11:26 +0800)]
MdeModulePkg/Core: fix too many available pages between BS_Data
The root cause is an unnecessary check to Size parameter in function
AdjustMemoryS(). It will cause one standalone free page (happen to have
Guard page around) in the free memory list cannot be allocated, even if
the requested memory size is less than a page.
//
// At least one more page needed for Guard page.
//
if (Size < (SizeRequested + EFI_PAGES_TO_SIZE (1))) {
return 0;
}
The following code in the same function actually covers above check
implicitly. So the fix is simply removing above check.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Laszlo Ersek [Wed, 7 Mar 2018 09:17:28 +0000 (10:17 +0100)]
BaseTools/header.makefile: revert gcc-8 "-Wno-xxx" options on OSX
I recently added the gcc-8 specific "-Wno-stringop-truncation" and
"-Wno-restrict" options to BUILD_CFLAGS, both for "Darwin" (XCODE5 /
clang, OSX) and otherwise (gcc, Linux / Cygwin).
I also regression-tested the change with gcc-4.8 on Linux -- gcc-4.8 does
not know either of the (gcc-8 specific) "-Wno-stringop-truncation" and
"-Wno-restrict" options, yet the build completed fine (by GCC design).
Regarding OSX, my expectation was that
- XCODE5 / clang would either recognize these warnings options (because
clang does recognize most -W options of gcc),
- or, similarly to gcc, clang would simply ignore the "-Wno-xxx" flags
that it didn't recognize.
Neither is the case; the new flags have broken the BaseTools build on OSX.
Revert them (for OSX only).
The ZeroMem() call goes beyond the HashInterfaceHob structure, causing
HOB list corruption. Instead, just clear the HashInterface fields, as
I suppose was originally intended.
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Chao Zhang <chao.b.zhang@intel.com> Cc: Star Zeng <star.zeng@intel.com> 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: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Chao Zhang <chao.b.zhang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Hao Wu [Tue, 6 Mar 2018 11:34:38 +0000 (19:34 +0800)]
MdeModulePkg/Core: Fix feature conflict between NX and Stack guard
If enabled, NX memory protection feature will mark some types of active
memory as NX (non-executable), which includes the first page of the stack.
This will overwrite the attributes of the first page of the stack if the
stack guard feature is also enabled.
The solution is to override the attributes setting to the first page of
the stack by adding back the 'EFI_MEMORY_RP' attribute when the stack
guard feature is enabled.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Hao Wu [Tue, 6 Mar 2018 10:36:37 +0000 (18:36 +0800)]
MdeModulePkg/Core: Refine handling NULL detection in NX setting
The commit rewrites the logic in function
InitializeDxeNxMemoryProtectionPolicy() for handling the first page
(page 0) when NULL pointer detection feature is enabled.
Instead of skip setting the page 0, the codes will now override the
attribute setting of page 0 by adding the 'EFI_MEMORY_RP' attribute.
The purpose is to make it easy for other special handling of pages
(e.g. the first page of the stack when stack guard feature is enabled).
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Hao Wu <hao.a.wu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com> Reviewed-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Function BmRepairAllControllers may recursively call itself if some
driver health protocol returns EfiDriverHealthStatusReconnectRequired.
However, driver health protocol of some buggy third party driver may
always return such status even after one and another reconnect. The
endless iteration will cause stack overflow and then system exception,
and it may be not easy to find that the exception is actually caused
by stack overflow.
So we limit the number of reconnect retry to 10 to improve code
robustness, and DEBUG_CODE is moved ahead before recursive repair to
track the repair result.
We also remove a duplicated declaration of BmRepairAllControllers() in
InternalBm.h in this patch, for it is only a trivial change.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Heyi Guo <heyi.guo@linaro.org> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Laszlo Ersek <lersek@redhat.com>
Ruiyu Ni [Tue, 6 Mar 2018 03:31:57 +0000 (11:31 +0800)]
MdeModulePkg/NullMemoryTest: Fix bug in CompatibleRangeTest
CompatibleRangeTest() contains two bugs:
1. It doesn't reject the memory above 16MB
2. it cannot handle the case when the partial or whole range of
requested memory is already tested.
The patch fixes the two bugs.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Marc Zyngier [Tue, 6 Mar 2018 13:00:35 +0000 (13:00 +0000)]
ArmPkg/TimerDxe: Always perform an EOI, even for spurious interrupts
The generic timer driver only EOIs the timer interrupt if
the ISTATUS bit is set. This is completely fine if you pretend
that spurious interrupts do not exist. But as a matter of fact,
they do, and the first one will leave the interrupt activated
at the GIC level, making sure that no other interrupt can make
it anymore.
Making sure that each interrupt Ack is paired with an EOI is the
way to go. Oh, and enabling the interrupt each time it is taken
is completely pointless. We entered this function for a good
reason...
Star Zeng [Wed, 14 Feb 2018 09:10:36 +0000 (17:10 +0800)]
IntelSiliconPkg VTdPmrPei: Return SUCCESS when Mapping == NULL in Unmap
NULL is returned to Mapping when Operation is BusMasterCommonBuffer or
BusMasterCommonBuffer64 in PeiIoMmuMap().
So Mapping == NULL is valid when calling PeiIoMmuUnmap().
940dbd071e9f01717236af236740aa0da716805f wrongly changed EFI_SUCCESS
to EFI_INVALID_PARAMETER when Mapping == NULL in PeiIoMmuUnmap().
This patch is to correct it.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Laszlo Ersek [Thu, 1 Mar 2018 21:05:55 +0000 (22:05 +0100)]
OvmfPkg/AmdSevDxe: decrypt the pages of the initial SMRAM save state map
Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:
[PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html
Original commit message from Brijesh:
> When OVMF is built with SMM, SMMSaved State area (SMM_DEFAULT_SMBASE +
> SMRAM_SAVE_STATE_MAP_OFFSET) contains data which need to be accessed by
> both guest and hypervisor. Since the data need to be accessed by both
> hence we must map the SMMSaved State area as unencrypted (i.e C-bit
> cleared).
>
> This patch clears the SavedStateArea address before SMBASE relocation.
> Currently, we do not clear the SavedStateArea address after SMBASE is
> relocated due to the following reasons:
>
> 1) Guest BIOS never access the relocated SavedStateArea.
>
> 2) The C-bit works on page-aligned address, but the SavedStateArea
> address is not a page-aligned. Theoretically, we could roundup the
> address and clear the C-bit of aligned address but looking carefully we
> found that some portion of the page contains code -- which will causes a
> bigger issue for the SEV guest. When SEV is enabled, all the code must
> be encrypted otherwise hardware will cause trap.
Changes by Laszlo:
- separate AmdSevDxe bits from SmmCpuFeaturesLib bits;
- spell out PcdLib dependency with #include and in LibraryClasses;
- replace (SMM_DEFAULT_SMBASE + SMRAM_SAVE_STATE_MAP_OFFSET) calculation
with call to new MemEncryptSevLocateInitialSmramSaveStateMapPages()
function;
- consequently, pass page-aligned BaseAddress to
MemEncryptSevClearPageEncMask();
- zero the pages before clearing the C-bit;
- pass Flush=TRUE to MemEncryptSevClearPageEncMask();
- harden the treatment of MemEncryptSevClearPageEncMask() failure.
Laszlo Ersek [Thu, 1 Mar 2018 19:59:12 +0000 (20:59 +0100)]
OvmfPkg/SmmCpuFeaturesLib: SEV: encrypt+free pages of init. save state map
Based on the following patch from Brijesh Singh <brijesh.singh@amd.com>:
[PATCH v2 1/2] OvmfPkg/AmdSevDxe: Clear the C-bit from SMM Saved State
http://mid.mail-archive.com/20180228161415.28723-2-brijesh.singh@amd.com
https://lists.01.org/pipermail/edk2-devel/2018-February/022016.html
Once PiSmmCpuDxeSmm relocates SMBASE for all VCPUs, the pages of the
initial SMRAM save state map can be re-encrypted (including zeroing them
out after setting the C-bit on them), and they can be released to DXE for
general use (undoing the allocation that we did in PlatformPei's
AmdSevInitialize() function).
The decryption of the same pages (which will occur chronologically
earlier) is implemented in the next patch; hence the "re-encryption" part
of this patch is currently a no-op. The series is structured like this in
order to be bisection-friendly. If the decryption patch preceded this
patch, then an info leak would be created while standing between the
patches.
Laszlo Ersek [Thu, 1 Mar 2018 16:59:19 +0000 (17:59 +0100)]
OvmfPkg/PlatformPei: SEV: allocate pages of initial SMRAM save state map
In the next two patches, we'll temporarily decrypt the pages containing
the initial SMRAM save state map, for SMBASE relocation. (Unlike the
separate, relocated SMRAM save state map of each VCPU, the original,
shared map behaves similarly to a "common buffer" between guest and host.)
The decryption will occur near the beginning of the DXE phase, in
AmdSevDxe, and the re-encryption will occur in PiSmmCpuDxeSmm, via OVMF's
SmmCpuFeaturesLib instance.
There is a non-trivial time gap between these two points, and the DXE
phase might use the pages overlapping the initial SMRAM save state map for
arbitrary purposes meanwhile. In order to prevent any information leak
towards the hypervisor, make sure the DXE phase puts nothing in those
pages until re-encryption is done.
Creating a memalloc HOB for the area in question is safe:
- the temporary SEC/PEI RAM (stack and heap) is based at
PcdOvmfSecPeiTempRamBase, which is above 8MB,
- the permanent PEI RAM (installed in PlatformPei's PublishPeiMemory()
function) never starts below PcdOvmfDxeMemFvBase, which is also above
8MB.
The allocated pages can be released to the DXE phase after SMBASE
relocation and re-encryption are complete.
Laszlo Ersek [Thu, 1 Mar 2018 16:31:44 +0000 (17:31 +0100)]
OvmfPkg/MemEncryptSevLib: find pages of initial SMRAM save state map
In the next three patches, we're going to modify three modules under
OvmfPkg. When OVMF is built with -D SMM_REQUIRE and runs in an SEV guest,
each affected module will have to know the page range that covers the
initial (pre-SMBASE relocation) SMRAM save state map. Add a helper
function to MemEncryptSevLib that calculates the "base address" and
"number of pages" constants for this page range.
(In a RELEASE build -- i.e., with assertions disabled and optimization
enabled --, the helper function can be compiled to store two constants
determined at compile time.)
Laszlo Ersek [Thu, 1 Mar 2018 17:55:09 +0000 (18:55 +0100)]
OvmfPkg/SmmCpuFeaturesLib: rewrap to 79 columns
There are many overlong lines; it's hard to work with the library like
this. Rewrap all files to 79 columns.
(
The rewrapping of the "mSmmCpuRegisterRanges" and "mSmmCpuWidthOffset"
arrays was verified by hexdumping the arrays in
SmmCpuFeaturesLibConstructor(), both before and after the patch, and
comparing the dumps.
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryEncrypted() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "clear" reference to the C-bit with a "set" reference.
Laszlo Ersek [Thu, 1 Mar 2018 14:15:39 +0000 (15:15 +0100)]
OvmfPkg/MemEncryptSevLib: clean up InternalMemEncryptSevSetMemoryDecrypted() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Document the
"Cr3BaseAddress" parameter, and correct several parameter references.
Replace a "set" reference to the C-bit with a "clear" reference.
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevSetPageEncMask() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Replace any
leftover "clear" references to the C-bit with "set" references. Also
remove any excess space in the comment block, and unindent the trailing
"**/" if necessary. Correct several parameter references.
Laszlo Ersek [Thu, 1 Mar 2018 13:41:01 +0000 (14:41 +0100)]
OvmfPkg/MemEncryptSevLib: clean up MemEncryptSevClearPageEncMask() decl
The declaration and the definition(s) of the function should have
identical leading comments and/or identical parameter lists. Also remove
any excess space in the comment block, and unindent the trailing "**/" if
necessary. Correct several parameter references.
projects / mirror_edk2.git / log