Star Zeng [Tue, 5 Jun 2018 08:04:38 +0000 (16:04 +0800)]
IntelSiliconPkg IntelVTdDxe: Fix incorrect code to clear VTd error
According to VTd spec, Software writes the value read from this
field (F) to Clear it. But current code is using 0 to clear the
field, that is incorrect.
And R_FSTS_REG register value clearing should be not in the for loop.
Without this patch, we will see same VTd error message appears again
and again after it occurs first time.
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>
Create the PlatformBootManagerProtocol that is used to add
predefined boot options in platform driver. This interface
will be used in ArmPkg/PlatformBootManagerLib.
Star Zeng [Mon, 4 Jun 2018 10:05:34 +0000 (18:05 +0800)]
IntelFrameworkPkg FrameworkUefiLib: Fix in EfiLocateProtocolBuffer()
Free HandleBuffer for error path in EfiLocateProtocolBuffer().
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Star Zeng [Fri, 13 Apr 2018 06:29:49 +0000 (14:29 +0800)]
MdePkg UefiLib: Fix in EfiLocateProtocolBuffer()
Free HandleBuffer for error path in EfiLocateProtocolBuffer().
Cc: Michael D Kinney <michael.d.kinney@intel.com> Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Ruiyu Ni [Fri, 1 Jun 2018 07:11:50 +0000 (15:11 +0800)]
MdeModulePkg: Make sure ResetSystemRuntimeDxe uses ResetSystemLibNull
Because the DxeResetSystemLib calls gRT->ResetSystem(), make sure
the gRT->ResetSystem() implementation doesn't call into
DxeResetSystemLib to avoid chicken-egg issue.
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: Liming Gao <liming.gao@intel.com>
Ruiyu Ni [Fri, 1 Jun 2018 07:09:58 +0000 (15:09 +0800)]
MdeModulePkg/DxeResetSystemLib: Avoid depending on UefiRuntimeLib
Current DxeResetSystemLib depends on UefiRuntimeLib because it calls
EfiResetSystem() API exposed by UefiRuntimeLib.
Due to the commit:
"MdePkg/UefiRuntimeLib: Do not allow to be linked by DXE driver"
which reverts UefiRuntimeLib to only support DXE_RUNTIME_DRIVER,
removing UefiRuntimeLib dependency makes the DxeResetSystemLib
can be used by DXE drivers.
The patch also disallows the DxeResetSystemLib to be linked by
runtime driver, SMM drivers.
Runtime driver cannot link to this library because the gRT is not
converted when entering to RT.
SMM driver cannot link to this library because calling RT services
from SMM after EndOfDxe violates security guideline.
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: Liming Gao <liming.gao@intel.com>
Ruiyu Ni [Fri, 1 Jun 2018 07:18:02 +0000 (15:18 +0800)]
MdePkg/UefiRuntimeLib: Do not allow to be linked by DXE driver
When UefiRuntimeLib links to a DXE driver, its constructor
still registers a Virtual Address Change event. The event callback
will get called when RT.SetVirtualAddressMap() is called from OS.
But when the driver is a DXE driver, the memory occupied by the
callback function might be zeroed or used by OS since the BS type
memory is free memory when entering to RT phase.
The patch reverts commit 97511979b4fdd84cf7cd51e43c22dc03e79bd4f3
"MdePkg/UefiRuntimeLib: Support more module types."
It makes sure that DXE driver cannot link to this library.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
X509_NAME_get_text_by_NID() used in X509GetCommonName() implementation
is one legacy function which have various limitations. The returned
data may be not usable when the target cert contains multicharacter
string type like a BMPString or a UTF8String.
This patch replaced the legacy function usage with more general
X509_NAME_get_index_by_NID() / X509_NAME_get_entry() APIs for X509
CommonName retrieving.
Tests: Validated the commonName retrieving with test certificates
containing PrintableString or BMPString data.
Cc: Ye Ting <ting.ye@intel.com> Cc: Michael Turner <Michael.Turner@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0 Signed-off-by: Long Qin <qin.long@intel.com> Reviewed-by: Ye Ting <ting.ye@intel.com>
Marcin Wojtas [Fri, 1 Jun 2018 13:58:13 +0000 (21:58 +0800)]
MdeModulePkg PeiCore: Check error status when processing boot FV
Until now the possible errors returned from processing
boot firmware volume were not checked, which could cause
misbehavior in further booting stages. Add relevant assert.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Marcin Wojtas <mw@semihalf.com> Signed-off-by: Jan Dabros <jsd@semihalf.com> Reviewed-by: Liming Gao <liming.gao@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Ard Biesheuvel [Tue, 22 May 2018 13:37:58 +0000 (15:37 +0200)]
MdeModulePkg/FirmwarePerformanceDataTableDxe: use AllocatePeiAccessiblePages
Replace the call to and implementation of the function
FpdtAllocateReservedMemoryBelow4G() with a call to
AllocatePeiAccessiblePages, which boils down to the same on X64,
but does not crash non-X64 systems that lack memory below 4 GB.
Ard Biesheuvel [Tue, 22 May 2018 13:36:16 +0000 (15:36 +0200)]
MdeModulePkg/DxeCorePerformanceLib: use AllocatePeiAccessiblePages
Replace the call to and implementation of the function
FpdtAllocateReservedMemoryBelow4G() with a call to
AllocatePeiAccessiblePages, which boils down to the same on X64,
but does not crash non-X64 systems that lack memory below 4 GB.
Add a routine to DxeServicesLib that abstracts the allocation of memory
that should be accessible by PEI after resuming from S3. We will use it
to replace open coded implementations that limit the address to < 4 GB,
which may not be possible on non-Intel systems that have no 32-bit
addressable memory at all.
Ard Biesheuvel [Tue, 22 May 2018 13:49:16 +0000 (15:49 +0200)]
ArmVirtPkg/PlatformBootManagerLib: add missing report status code call
Consumers of status code reports may rely on a status code to be
reported when the ReadyToBoot event is signalled. For instance,
FirmwarePerformanceDxe will fail to install the FPDT ACPI table
in this case. So add the missing call.
Ard Biesheuvel [Tue, 22 May 2018 13:46:51 +0000 (15:46 +0200)]
OvmfPkg/PlatformBootManagerLib: add missing report status code call
Consumers of status code reports may rely on a status code to be
reported when the ReadyToBoot event is signalled. For instance,
FirmwarePerformanceDxe will fail to install the FPDT ACPI table
in this case. So add the missing call.
(For builds that don't need this DXEFV bump, I've checked the
FVMAIN_COMPACT increase stemming from the additional 1MB padding, using
NOOPT + GCC48 + FD_SIZE_2MB, and no other "-D" flags. In the IA32 build,
FVMAIN_COMPACT grows by 232 bytes. In the IA32X64 build, FVMAIN_COMPACT
shrinks by 64 bytes. In the X64 build, FVMAIN_COMPACT shrinks by 376
bytes.)
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org> Cc: Gary 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: Ard Biesheuvel <ard.biesheuvel@linaro.org> Reviewed-by: Gary Lin <glin@suse.com>
Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib.
This allows the platform to inform the user of progress when a
firmware storage device is being updated with a new firmware
image.
Cc: Kelly Steele <kelly.steele@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Kelly Steele <kelly.steele@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Add PerformFlashWriteWithProgress() to the PlatformFlashAccessLib.
This allows the platform to inform the user of progress when a
firmware storage device is being updated with a new firmware
image.
Cc: David Wei <david.wei@intel.com> Cc: Mang Guo <mang.guo@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: David Wei <david.wei@intel.com>
Add a new API to the PlatformFlashAccessLib that passes
in an optional Progress() function along with a start and
end percentage to call the Progress() function with.
If the Progress() function is not NULL, then it is the
Progress() function that was passed into the Firmware
Management Protocol SetImage() services and is used
to update the user on the progress as a firmware device
is updated with a firmware image.
Implementations of the PlatformFlashAccessLib are
recommended to call the Progress() function as work
is performed to update to contents of a firmware
storage device.
Cc: Jiewen Yao <jiewen.yao@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
Add DisplayUpdateProgressLib instances for text consoles
and graphical consoles.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Based on content from the following branch/commits:
https://github.com/Microsoft/MS_UEFI/tree/share/MsCapsuleSupport
Add the DisplayUpdateProgressLib class that is used
to inform the user of progress during updates of
firmware images in firmware devices. A platform
specific instance of this library can be used to
customize how the user is informed of progress.
Add the EDK II Firmware Management Progress Protocol.
This is an optional protocol that must be installed
onto the same handle as a Firmware Management Protocol.
This new protocol provides the color of a progress
bar that allows different firmware devices to use
different colors during a firmware update. It also
provides a watchdog timer value in seconds that is
armed each time the Progress() service passed
into Firmware Management Protocol SetImage()
is called.
Cc: Sean Brogan <sean.brogan@microsoft.com> Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Reviewed-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Ruiyu Ni [Fri, 25 May 2018 09:00:16 +0000 (17:00 +0800)]
UefiCpuPkg/CpuCommonFeatures: Follow SDM for MAX CPUID feature detect
According to IA manual:
"Before setting this bit (MSR_IA32_MISC_ENABLE[22]) , BIOS must
execute the CPUID.0H and examine the maximum value returned in
EAX[7:0]. If the maximum value is greater than 2, this bit is
supported."
We need to fix our current detection logic to compare against 2.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Eric Dong <eric.dong@intel.com> Cc: Ming Shao <ming.shao@intel.com>
Ruiyu Ni [Fri, 25 May 2018 08:29:48 +0000 (16:29 +0800)]
PcAtChipsetPkg/PcRtc: Add two new PCD for RTC Index/Target registers
In certain HW implementation, the BIT7 of RTC Index register(0x70) is
for NMI sources enable/disable but the BIT7 of 0x70 cannot be read
before writing. Software which doesn't want to change the NMI sources
enable/disable setting can write to the alias register 0x74, through
which only BIT0 ~ BIT6 of 0x70 is modified.
So two new PCDs are added so that platform can have the flexibility
to change the default RTC register addresses from 0x70/0x71 to
0x74/0x75.
With the new PCDs added, it can also support special HW that provides
RTC storage in a different register pairs.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
For case-insensitive file systems, edk2 String.py collides with the
Python string.py, which results in build errors. This,for example,
applies to building via the Windows Subsystem for Linux from a
DriveFS file system. This patch renames String to StringUtils to
prevent conflicts for case-insensitive file systems.
The EvaluateConditional function should not call GetRealFileLine
because this is already done in Warning init and only needs to be
calculated in the event of a parsing failure. This fix stops
InsertedLines from being subtracted twice during error handling.
Ruiyu Ni [Wed, 23 May 2018 03:28:46 +0000 (11:28 +0800)]
MdeModulePkg/PciBus: Use actual max bus # for subordinary bus #
Current code assumes the max bus(0xFF) is under this P2P bridge and
temporarily set it as subordinate bus.
It may cause silicon hangs during PCI enumeration in some specific
case.
Instead, it should get the max bus number from the bus number
resources returned from
PCI_HOST_BRIDGE_RESOURCE_ALLOCATION.StartBusEnumeration() and set it
as subordinate bus.
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
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.
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>
projects / mirror_edk2.git / log