Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to
their single respective instances under OvmfPkg. Later patches will use
those lib classes in OvmfPkg drivers, some of which are included in
ArmVirt platforms.
Resolve the PciCapLib, PciCapPciSegmentLib, and PciCapPciIoLib classes to
their single respective instances. Later patches will use these lib
classes in OvmfPkg drivers.
Add a library class, and a UEFI_DRIVER lib instance, that are layered on
top of PciCapLib, and allow clients to plug an EFI_PCI_IO_PROTOCOL backend
into PciCapLib, for config space access.
(Side note:
Although the UEFI spec says that EFI_PCI_IO_PROTOCOL_CONFIG() returns
EFI_UNSUPPORTED if "[t]he address range specified by Offset, Width, and
Count is not valid for the PCI configuration header of the PCI
controller", this patch doesn't directly document the EFI_UNSUPPORTED
error code, for ProtoDevTransferConfig() and its callers
ProtoDevReadConfig() and ProtoDevWriteConfig(). Instead, the patch refers
to "unspecified error codes". The reason is that in edk2, the
PciIoConfigRead() and PciIoConfigWrite() functions [1] can also return
EFI_INVALID_PARAMETER for the above situation.
Namely, PciIoConfigRead() and PciIoConfigWrite() first call
PciIoVerifyConfigAccess(), which indeed produces the standard
EFI_UNSUPPORTED error code, if the device's config space is exceeded.
However, if PciIoVerifyConfigAccess() passes, and we reach
RootBridgeIoPciRead() and RootBridgeIoPciWrite() [2], then
RootBridgeIoCheckParameter() can still fail, e.g. if the root bridge
doesn't support extended config space (see commit 014b472053ae3).
For all kinds of Limit violations in IO, MMIO, and config space,
RootBridgeIoCheckParameter() returns EFI_INVALID_PARAMETER, not
EFI_UNSUPPORTED. That error code is then propagated up to, and out of,
PciIoConfigRead() and PciIoConfigWrite().
Add a library class, and a BASE lib instance, that are layered on top of
PciCapLib, and allow clients to plug a PciSegmentLib backend into
PciCapLib, for config space access.
(Side note:
The "MaxDomain" parameter is provided because, in practice, platforms
exist where a PCI Express device may show up on a root bridge such that
the root bridge doesn't support access to extended config space. Earlier
the same issue was handled for MdeModulePkg/PciHostBridgeDxe in commit 014b472053ae3. However, that solution does not apply to the PciSegmentLib
class, because:
(1) The config space accessor functions of the PciSegmentLib class, such
as PciSegmentReadBuffer(), have no way of informing the caller whether
access to extended config space actually succeeds.
(For example, in the UefiPciSegmentLibPciRootBridgeIo instace, which
could in theory benefit from commit 014b472053ae3, the
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() status code is explicitly
ignored, because there's no way for the lib instance to propagate it
to the PciSegmentLib caller. If the
EFI_PCI_ROOT_BRIDGE_IO_PROTOCOL.Pci.Read() call fails, then
DxePciSegmentLibPciRootBridgeIoReadWorker() returns Data with
indeterminate value.)
(2) There is no *general* way for any firmware platform to provide, or
use, a PciSegmentLib instance in which access to extended config space
always succeeds.
In brief, on a platform where config space may be limited to 256 bytes,
access to extended config space through PciSegmentLib may invoke undefined
behavior; therefore PciCapPciSegmentLib must give platforms a way to
prevent such access.)
Add a library class, and a BASE lib instance, to work more easily with PCI
capabilities in PCI config space. Functions are provided to parse
capabilities lists, and to locate, describe, read and write capabilities.
PCI config space access is abstracted away.
Laszlo Ersek [Fri, 18 May 2018 17:20:32 +0000 (19:20 +0200)]
BaseTools/tools_def: add "-fno-unwind-tables" to GCC_AARCH64_CC_FLAGS
The ElfConvert routines in GenFw don't handle the ".eh_frame" ELF section
emitted by gcc. For this reason, Leif disabled the generation of that
section for AARCH64 with "-fno-asynchronous-unwind-tables" in commit 28e80befa4fe [1], and Ard did the same for IA32 and X64 in commit 26ecc55c027d [2]. (The CLANG38 toolchain received the same flag at its
inception, in commit 6f756db5ea05 [3].)
However, ".eh_frame" is back now; in upstream gcc commit 9cbee213b579 [4]
(part of tag "gcc-8_1_0-release"), both "-fasynchronous-unwind-tables" and
"-funwind-tables" were made the default for AARCH64. (The patch author
described the effects on the gcc mailing list [5].) We have to counter the
latter flag with "-fno-unwind-tables", otherwise GenFw chokes on
".eh_frame" again (triggered for example on Fedora 28).
"-f[no-]unwind-tables" goes back to at least gcc-4.4 [6], so it's safe to
add to GCC_AARCH64_CC_FLAGS.
Marvin Haeuser [Tue, 22 May 2018 11:48:29 +0000 (19:48 +0800)]
BaseTools/Workspace: Fix ValueChain set
Commit 88252a90d1ca7846731cd2e4e8e860454f7d97a3 changed ValueChain
from a dict to a set, but also changed the (former) key type from a
touple to two separate values, which was probably unintended and also
breaks build for packages involving Structured PCDs, because add()
only takes one argument.
This commit changes the values back to touples.
OvmfPkg/PlatformBootManagerLib: process TPM PPI request
Call Tcg2PhysicalPresenceLibProcessRequest() to process pending PPI
requests from PlatformBootManagerAfterConsole().
Laszlo understanding of edk2 is that the PPI operation processing was
meant to occur *entirely* before End-Of-Dxe, so that 3rd party UEFI
drivers couldn't interfere with PPI opcode processing *at all*.
He suggested that we should *not* call
Tcg2PhysicalPresenceLibProcessRequest() from BeforeConsole(). Because,
an "auth" console, i.e. one that does not depend on a 3rd party
driver, is *in general* impossible to guarantee. Instead we could opt
to trust 3rd party drivers, and use the "normal" console(s) in
AfterConsole(), in order to let the user confirm the PPI requests. It
will depend on the user to enable Secure Boot, so that the
trustworthiness of those 3rd party drivers is ensured. If an attacker
roots the guest OS from within, queues some TPM2 PPI requests, and
also modifies drivers on the EFI system partition and/or in GPU option
ROMs (?), then those drivers will not load after guest reboot, and
thus the dependent console(s) won't be used for confirming the PPI
requests.
- 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>
Yunhua Feng [Wed, 16 May 2018 05:59:59 +0000 (13:59 +0800)]
BaseTools: Report more clear error message when PCD type mismatch
Error message is not clear when PCD type defined in driver's Library
is different with PCD type defined in DSC components or PCD type
defined in DSC PCD section.
Case as below:
DSC:
[PcdsFixedAtBuild]
PcdToken.PcdCName | "A"
[Components]
TestPkg/TestDriver.inf {
<PcdsPatchableInModule>
PcdToken.PcdCName | "B"
}
Library:
[Pcd]
PcdToken.PcdCName
Yunhua Feng [Mon, 14 May 2018 01:54:46 +0000 (09:54 +0800)]
BaseTools: Library PCD type will inherit from the driver
If a PCD is not referenced in global PCD section of DSC file at all,
but is referenced in module scope, then the default PCD type for libs
should be the module scoped PCD type.
Yunhua Feng [Thu, 10 May 2018 08:47:44 +0000 (16:47 +0800)]
BaseTools: Fix bug PCD type in component is not same with Pcd section
Per DSC spec 3.11 [Components] Sections:
The PCD access methods (and storage methods) are selected on a platform
basis - it is not permitted to have a PCD listed in one of the Pcd
sections and use it differently in an individual module. For example,
if a PCD is listed in a [PcdsFixedAtBuild] section, it is not permitted
to list it in a <PcdsPatchableInModule> sub-section of an INF file.
but current code doesn't report error for this case.
BaseTools: Separate HOST and PREFIX env for GCC tool chain
The crossing GCC compiler may use the different path for make and gcc tool.
So, GCC_HOST_BIN is introduced for make path. GCC5_BIN is still kept for
gcc path. User needs to set GCC_HOST_BIN besides set GCC5_BIN env if
the default make is not used. Normally, make is in the default system path.
GCC_HOST_BIN is not required to be set.
Dandan Bi [Fri, 18 May 2018 06:15:06 +0000 (14:15 +0800)]
IntelFrameworkPkg/UefiLib: Fix build fail caused by commit b6d5def2fa
In commit b6d5def2faf56334128ea2f056356d7e3852831e
when adding 'OUT' decorator for the parameter in AddUnicodeString(),
it delete the function name by mistake. This patch is to fix this
issue.
Ruiyu Ni [Wed, 9 May 2018 09:36:06 +0000 (17:36 +0800)]
MdePkg/SmmPeriodicSmiLib: Get Periodic SMI Context More Robustly
The PeriodicSmiDispatchFunction() in SmmPeriodicSmiLib may assert
with "Bad CR signature".
Currently, the SetActivePeriodicSmiLibraryHandler() function
(invoked at the beginning of the PeriodicSmiDispatchFunction()
function) attempts to locate the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT
structure pointer for the current periodic SMI from a given
EFI_SMM_PERIODIC_TIMER_REGISTER_CONTEXT (RegiserContext) structure
pointer (using the CR macro).
The RegisterContext structure pointer passed to the
PeriodicSmiDispatchFunction() is assumed to point to the same
RegisterContext structure address given to the
SmmPeriodicTimerDispatch2 protocol Register() API in
PeriodicSmiEnable().
However, certain SmmPeriodicTimerDispatch2 implementation may copy
the RegisterContext to a local buffer and pass that address as the
context to PeriodicSmiDispatchFunction() in which case usage of the
CR macro to find the parent structure base fails.
The patch uses the LookupPeriodicSmiLibraryHandler() function to
find the PERIODIC_SMI_LIBRARY_HANDLER_CONTEXT structure pointer.
This works even in this scenario since the DispatchHandle returned
from the SmmPeriodicTimerDispatch2 Register() function uniquely
identifies that registration.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com> Reviewed-by: Liming Gao <liming.gao@intel.com>
Laszlo Ersek [Thu, 17 May 2018 19:51:11 +0000 (21:51 +0200)]
OvmfPkg/PlatformBootManagerLib: connect Virtio RNG devices again
Virtio RNG devices are never boot devices, so in commit 245c643cc8b7 we
stopped connecting them. This is a problem because an OS boot loader may
depend on EFI_RNG_PROTOCOL to seed the OS's RNG.
Connect Virtio RNG devices again. And, while commit 245c643cc8b7 removed
that from PlatformBootManagerAfterConsole(), reintroduce it now to
PlatformBootManagerBeforeConsole() -- this way Driver#### options launched
between both functions may access EFI_RNG_PROTOCOL too.
Laszlo Ersek [Thu, 17 May 2018 19:51:11 +0000 (21:51 +0200)]
ArmVirtPkg/PlatformBootManagerLib: connect Virtio RNG devices again
Virtio RNG devices are never boot devices, so in commit ff1d0fbfbaec we
stopped connecting them. This is a problem because an OS boot loader may
depend on EFI_RNG_PROTOCOL to seed the OS's RNG.
Connect Virtio RNG devices again. And, while commit ff1d0fbfbaec removed
that from PlatformBootManagerAfterConsole(), reintroduce it now to
PlatformBootManagerBeforeConsole() -- this way Driver#### options launched
between both functions may access EFI_RNG_PROTOCOL too.
IntelFrameworkPkg/FrameworkUefiLib: Add 'OUT' decorator where necessary.
The functions AddUnicodeString() and AddUnicodeString2() might return
a new value into their parameter UnicodeStringTable, hence add the
appropiate 'OUT' decorator.
MdePkg/UefiLib: Add 'OUT' decorator where necessary.
The functions AddUnicodeString() and AddUnicodeString2() might return
a new value into their parameter UnicodeStringTable, hence add the
appropiate 'OUT' decorator.
MdePkg/PeiServicesLib: Decorate 'PpiDescriptor' as OPTIONAL for LocatePpi().
The UEFI PI specification defines PpiDescriptor to be OPTIONAL for
the LocatePpi PEI Service. This patch reflects this in the function
declaration and definition of the corresponding PeiServices library
function.
Lin, Derek [Wed, 9 May 2018 09:03:23 +0000 (17:03 +0800)]
BaseTools: Fix --hash Package and Module hash value.
The order of List enumeration is arbitrary.
Need to be sorted while calculating Package/Module hash, otherwise it
generate different hash value even nothing changes.
Eric Dong [Mon, 14 May 2018 07:28:40 +0000 (15:28 +0800)]
SecurityPkg/OpalPassword: Fix PSID revert no hint message.
For no warning message when do the PSID revert action, the
message in the popup dialog is not enough. The error use
of NULL for CreatePopUp function caused this regression.
This change fixed it.
If both ConIn and ConOut exist, but ConIn references none of the PS/2
keyboard, the USB wild-card keyboard, and any serial ports, then
PlatformInitializeConsole() currently allows the boot to proceed without
any input devices at all. This makes for a bad user experience -- the
firmware menu could only be entered through OsIndications, set by a guest
OS.
Do what ArmVirtQemu does already, namely connect the consoles, and add
them to ConIn / ConOut / ErrOut, unconditionally. (The underlying
EfiBootManagerUpdateConsoleVariable() function checks for duplicates.)
The issue used to be masked by the EfiBootManagerConnectAll() call that
got conditionalized in commit 245c643cc8b7.
Yunhua Feng [Mon, 7 May 2018 10:26:24 +0000 (18:26 +0800)]
BaseTools: Fix generating array's size is incorrect in AutoGen.c
case example:
DSC:
[PcdsFixedAtBuild]
PcdToken.PcdName | "A"
[Components]
TestPkg/TestDriver.inf {
PcdToken.PcdName | {0x41,0x42,0x43,0x44}
}
Generating the size of array is incorrect in AutoGen.c
GLOBAL_REMOVE_IF_UNREFERENCED const UINT8
_gPcd_FixedAtBuild_PcdName[2] = {0x41,0x42,0x43,0x44};
Bi, Dandan [Wed, 9 May 2018 05:02:11 +0000 (13:02 +0800)]
BaseTools/VfrCompile: Avoid using uninitialized pointer
V2:
Add function _INIT_OPHDR_COND () for variable initialization.
Make code logic more clean.
Previously _CLEAR_SAVED_OPHDR () is used for variable
initialization, and we updated it to clean memory.
But _CLEAR_SAVED_OPHDR () is still called for variable
initialization. This will cause uninitialized pointer
will be checked to free and cause unexpected issue.
This patch is to add new function for variable initialization
and keep _CLEAR_SAVED_OPHDR () to clean memory which is
aligned with its function name.
Cc: Liming Gao <liming.gao@intel.com> Cc: Gary Lin <glin@suse.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Dandan Bi <dandan.bi@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com>
Ruiyu Ni [Mon, 23 Apr 2018 06:20:26 +0000 (14:20 +0800)]
MdeModulePkg/PciHostBridge: Count the (mm)io overhead when polling
RootBridgeIo.PollMem()/PollIo() originally don't count the IO/MMIO
access overhead when delaying.
The patch changes the implementation to count the access overhead
so that the actually delay equals to user required delay.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com>
Ruiyu Ni [Wed, 25 Apr 2018 07:05:54 +0000 (15:05 +0800)]
IntelFrameworkModule/LegacyBios: Use reserved memory for legacy data
Certain Legacy USB implementation needs to access legacy data (BDA,
etc.) from SMM environment. While currently it's not allowed to
access BS memory from SMM after EndofDxe, change the legacy data
to use reserved memory type.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Laszlo Ersek [Mon, 7 May 2018 19:59:23 +0000 (21:59 +0200)]
CryptoPkg/CrtLibSupport: add secure_getenv() stub function
The Fedora distro ships a modified OpenSSL 1.1.0 package stream. One of
their patches calls the secure_getenv() C library function. We already
have a stub for getenv(); it applies trivially to secure_getenv() as well.
Add the secure_getenv() stub so that edk2 can be built with Fedora's
OpenSSL 1.1.0 sources.
Cc: Qin Long <qin.long@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Long Qin <qin.long@intel.com>
MdeModulePkg/AcpiPlatformDxe: Unload after execution.
AcpiPlatformDxe solely performs one-time tasks and does not expose
any services or create any events. Hence it can safely be unloaded
after the Entry Point execution by returning an error code.
Star Zeng [Thu, 26 Apr 2018 09:16:47 +0000 (17:16 +0800)]
MdeModulePkg CapsuleApp: Check Buffer against NULL before freeing it
If the capsule from command line is not present,
Buffer will be random value when freeing it in DumpCapsule(),
then ASSERT will happen or other memory pool may be freed.
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>
Jiaxin Wu [Fri, 4 May 2018 03:48:43 +0000 (11:48 +0800)]
NetworkPkg/NetworkPkg.dsc: Add the instance of library class [SafeIntLib].
This patch is to add the instance of library class [SafeIntLib] to fix the
NetworkPkg build error, which is caused by the commit of 2167c7f7 that the
TlsLib will always consume SafeIntLib.
Cc: Ye Ting <ting.ye@intel.com> Cc: Fu Siyuan <siyuan.fu@intel.com> Cc: Long Qin <qin.long@intel.com> Cc: Bi Dandan <dandan.bi@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Wu Jiaxin <jiaxin.wu@intel.com> Reviewed-by: Long Qin <qin.long@intel.com>
Carsey, Jaben [Fri, 4 May 2018 20:25:16 +0000 (04:25 +0800)]
BaseTools: Ecc - add dict for config file to internal translation
Commit eece4292acc80 changed a variable name, which was tied directly to
a config file entry. This seperates the internal variable names from
the config file entries by having the internal dict accessed through a
translation of key words.
added a test when this is run straight from command line.
currently GUID packing and pack size determination is spread
throughout the code. This introduces a shared function and dict and
routes all code paths through them.
projects / mirror_edk2.git / log