IntelFrameworkModulePkg IsaSerialDxe: Update algorithm to calculate Divisor
To align the way in MdeModulePkg SerialPortLib and PciSioSerialDxe driver,
Divisor is added by one when the reminder is more than half (16 * BaudRate).
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Liming Gao <liming.gao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
OvmfPkg/PlatformBootManagerLib: add USB keyboard to ConIn
PlatformInitializeConsole() (called by PlatformBootManagerBeforeConsole())
adds elements of "gPlatformConsole" to ConIn / ConOut / ErrOut (as
requested per element) if at boot at least one of ConIn and ConOut doesn't
exist. This typically applies to new VMs, and VMs with freshly recreated
varstores.
Add a USB keyboard wildcard to ConIn via "gPlatformConsole", so that we
not only bind the PS/2 keyboard. (The PS/2 keyboard is added in
PrepareLpcBridgeDevicePath()). Explicitly connecting the USB keyboard is
necessary after commit 245c643cc8b7.
Dandan Bi [Tue, 10 Apr 2018 05:51:08 +0000 (13:51 +0800)]
MdeModulePkg/FPDT: Add error message for unsupported case
We have updated performance infrastructure in previous commits:
between
https://github.com/tianocore/edk2/commit/73fef64f14d1b97ae9bd4705df3becc022391eba
and
https://github.com/tianocore/edk2/commit/115eae650bfd2be2c2bc37360f4a755065e774c4
Update FPDT drivers to collect the performance data reported by
gEdkiiFpdtExtendedFirmwarePerformanceGuid.
The old implementation which collected performance data through
gEfiFirmwarePerformanceGuid is not supported now.
We should add error message to remind user for this unsupported
case in case anyone use it by mistake.
Star Zeng [Fri, 13 Apr 2018 09:55:14 +0000 (17:55 +0800)]
SignedCapsulePkg SystemFirmwareUpdateDxe: Fix failure caused by d69d922
d69d9227d046211265de1fab5580c50a65944614 caused system firmware update
failure. It is because FindMatchingFmpHandles() is expected to return
handles matched, but the function returns all handles found.
This patch is to fix the issue.
This patch also assigns mSystemFmpPrivate->Handle for "case 1:" path
in case the Handle is needed by other place in future.
Cc: Michael D Kinney <michael.d.kinney@intel.com> 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> Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
(V2 Update:
Removing the wrong "--remote" option from git submodule update
command in this commit message. Thanks Laszlo's clarification
to correct this)
Update OpenSSL version to 1.1.0h release (27-Mar-2018) to include the
fix for CVE-2018-0739 issue (Handling of crafted recursive ASN.1
structures can cause a stack overflow and resulting denial of service,
Refer to https://www.openssl.org/news/secadv/20180327.txt for more
information).
Please note "git pull" will not update the submodule repository.
use the following commend to make your existing submodule track this
update:
$ git submodule update --recursive
Long Qin [Thu, 12 Apr 2018 02:50:30 +0000 (10:50 +0800)]
CryptoPkg/OpensslLib: Fix the documentation about submodule update
This patch is to drop "--remote" option from the original suggested
submodule update command ("$ git submodule update --recursive
--remote") in HOWTO document.
"--remote" option will integrate changes from the upstream subproject
with the submodules's "current HEAD", instead of using the edk2
superproject's "recorded SHA-1".
It is important here for the edk2 consumers to updating the working
tree of the submodules to match the commit / release tag that the
superproject expects. So removing "--remote" option to fix this
documentation issue here.
Laszlo Ersek [Sat, 31 Mar 2018 15:33:14 +0000 (17:33 +0200)]
CryptoPkg/TlsLib: rewrite TlsSetCipherList()
Rewrite the TlsSetCipherList() function in order to fix the following
issues:
- Any cipher identifier in CipherId that is not recognized by
TlsGetCipherMapping() will cause the function to return EFI_UNSUPPORTED.
This is a problem because CipherId is an ordered preference list, and a
caller should not get EFI_UNSUPPORTED just because it has an elaborate
CipherId preference list. Instead, we can filter out cipher identifiers
that we don't recognize, as long as we keep the relative order intact.
- CipherString is allocated on the stack, with 500 bytes.
While processing a large CipherId preference list, this room may not be
enough. Although no buffer overflow is possible, CipherString exhaustion
can lead to a failed TLS connection, because any cipher names that don't
fit on CipherString cannot be negotiated.
Compute CipherStringSize first, and allocate CipherString dynamically.
- Finally, the "@STRENGTH" pseudo cipher name is appended to CipherString.
(Assuming there is enough room left in CipherString.) This causes
OpenSSL to sort the cipher list "in order of encryption algorithm key
length".
This is a bad idea. The caller specifically passes an ordered preference
list in CipherId. Therefore TlsSetCipherList() must not ask OpenSSL to
reorder the list, for any reason. Drop "@STRENGTH".
While at it, fix and unify the documentation of the CipherId parameter.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=915
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Laszlo Ersek [Sat, 31 Mar 2018 20:25:15 +0000 (22:25 +0200)]
CryptoPkg/TlsLib: sanitize lib classes in internal header and INF
"InternalTlsLib.h" includes "BaseCryptLib.h", but the lib class is not
listed in the INF file.
The INF file lists a good number of lib classes, but none of the lib class
headers are included by "InternalTlsLib.h".
Synchronize & sort both lists, while removing those library classes that
aren't actually needed. (IntrinsicLib and OpensslLib have no edk2 class
headers.)
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=915
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
CryptoPkg/TlsLib: pre-compute OpensslCipherLength in TlsCipherMappingTable
In the next patches, we'll need the lengths of the
TLS_CIPHER_MAPPING.OpensslCipher string fields. These lengths can be
computed at build time; add the new field "OpensslCipherLength", and
introduce the MAP() macro for populating it.
While at it, add some horizontal whitespace to "TlsCipherMappingTable",
and add a comma after the last element. This will come handy in a later
patch.
(The patch does not change the first two columns of
"TlsCipherMappingTable", which can be easily verified with "git show
--word-diff".)
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=915
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Laszlo Ersek [Sat, 31 Mar 2018 15:06:39 +0000 (17:06 +0200)]
CryptoPkg/TlsLib: use binary search in the TlsGetCipherMapping() function
Improve the performance of the TlsGetCipherMapping() function by adopting
the binary search from DhcpFindOptionFormat()
[MdeModulePkg/Universal/Network/Dhcp4Dxe/Dhcp4Option.c].
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=915
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
CryptoPkg/TlsLib: replace TlsGetCipherString() with TlsGetCipherMapping()
In the following patches it will be useful if the IANA CipherId lookup
returns a pointer to the whole matching IANA-to-OpenSSL mapping structure,
not just the OpenSSL cipher suite name. Rename TLS_CIPHER_PAIR and
TlsGetCipherString() to TLS_CIPHER_MAPPING and TlsGetCipherMapping()
respectively, and make the function return a pointer to
TLS_CIPHER_MAPPING.
Cc: Jiaxin Wu <jiaxin.wu@intel.com> Cc: Qin Long <qin.long@intel.com> Cc: Siyuan Fu <siyuan.fu@intel.com> Cc: Ting Ye <ting.ye@intel.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=915
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Laszlo Ersek <lersek@redhat.com> Reviewed-by: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
Laszlo Ersek [Sat, 31 Mar 2018 14:36:39 +0000 (16:36 +0200)]
NetworkPkg/TlsDxe: clean up byte order conversion for EfiTlsCipherList
Fix the following style issues:
- "Data" is accessed through a pointer to UINT16 rather than to a pointer
to EFI_TLS_CIPHER. While technically correct, UINT16 is harder to
interpret against the UEFI spec.
- Array subscripting is written with weird *(Pointer + Offset)
expressions, rather than with Pointer[Offset].
- The byte order is converted with HTONS(), while it should be NTOHS().
Either way, use the Data1 and Data2 fields of EFI_TLS_CIPHER instead.
Laszlo Ersek [Sat, 31 Mar 2018 14:04:10 +0000 (16:04 +0200)]
NetworkPkg/TlsDxe: verify DataSize for EfiTlsCipherList
TlsSetSessionData() shouldn't just ignore an incomplete EFI_TLS_CIPHER
element at the end of "Data":
- Generally speaking, malformed input for a security API is best rejected
explicitly.
- Specifically speaking, the size of EFI_TLS_CIPHER is 2 bytes. If
DataSize is 1 on input, then the initial check for (DataSize == 0) will
fail, but then TlsSetCipherList() will be called with CipherNum=0.
Return EFI_INVALID_PARAMETER from TlsSetSessionData() if "Data" doesn't
contain a whole number of EFI_TLS_CIPHER elements. While at it, introduce
the dedicated variable CipherCount.
Laszlo Ersek [Sat, 31 Mar 2018 23:27:43 +0000 (01:27 +0200)]
OvmfPkg/TlsAuthConfigLib: configure trusted cipher suites for HTTPS boot
Read the list of trusted cipher suites from fw_cfg and to store it to
EDKII_HTTP_TLS_CIPHER_LIST_VARIABLE.
The fw_cfg file will be formatted by the "update-crypto-policies" utility
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 forwarded by NetworkPkg/HttpDxe (in TlsConfigCipherList()) to
NetworkPkg/TlsDxe (TlsSetSessionData()) and TlsLib (TlsSetCipherList()).
Note: the development of the "update-crypto-policies" feature is underway
at this time. Meanwhile the following script can be used to generate the
binary file for fw_cfg:
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: Long Qin <qin.long@intel.com> Reviewed-by: Jiaxin Wu <jiaxin.wu@intel.com>
[lersek@redhat.com: update commit msg and add script as requested by Gary]
[lersek@redhat.com: update commit msg as requested by Jiaxin]
This issue will only happen if PcdDxeNxMemoryProtectionPolicy is
enabled for reserved memory, which will mark SMM RAM as NX (non-
executable) during DXE core initialization. SMM IPL driver will
unset the NX attribute for SMM RAM to allow loading and running
SMM core/drivers.
But above commit will fail the unset operation of the NX attribute
due to a fact that SMM RAM has zero cache attribute (MRC code always
sets 0 attribute to reserved memory), which will cause GCD internal
method ConverToCpuArchAttributes() to return 0 attribute, which is
taken as invalid CPU paging attribute and skip the calling of
gCpu->SetMemoryAttributes().
The solution is to make use of existing functionality in PiSmmIpl
to make sure one cache attribute is set for SMM RAM. For performance
consideration, PiSmmIpl will always try to set SMM RAM to write-back.
But there's a hole in the code which will fail the setting write-back
attribute because of no corresponding cache capabilities. This patch
will add necessary cache capabilities before setting corresponding
attributes.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
MdeModulePkg/SmmCore: add sanity check for SetMemoryAttributes
Heap Guard feature needs enough memory and paging to work. Otherwise
calling SetMemoryAttributes to change page attribute will fail. This
patch add necessary check of result of calling SetMemoryAttributes.
This can help users to debug their problem in enabling this feature.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
MdeModulePkg/DxeCore: add sanity check for SetMemoryAttributes
Heap Guard feature needs enough memory and paging to work. Otherwise
calling SetMemoryAttributes to change page attribute will fail. This
patch add necessary check of result of calling SetMemoryAttributes.
This can help users to debug their problem in enabling this feature.
Cc: Star Zeng <star.zeng@intel.com> Cc: Eric Dong <eric.dong@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Jian J Wang <jian.j.wang@intel.com> Reviewed-by: Star Zeng <star.zeng@intel.com>
Star Zeng [Wed, 28 Mar 2018 08:50:00 +0000 (16:50 +0800)]
SignedCapsulePkg SystemCapsuleLib: Change some dbg level to DEBUG_INFO
This debug message should be info instead of error. This patch is to
change the debug level to DEBUG_INFO.
DEBUG((DEBUG_ERROR, "checking FV....0x%08x - 0x%x\n",
FvHeader, FvHeader->FvLength)); // "Mark"
This comment is inaccurate. This patch is to remove it.
//
// Check section
//
This debug message should be removed as FvHeader may have been out of
range FdStart and FdSize, and the loop will go to "Mark" above again if
FvHeader is not out of range FdStart and FdSize, and then that debug
message will be shown. This patch is to remove this debug message.
DEBUG((DEBUG_ERROR, "Next FV....0x%08x - 0x%x\n",
FvHeader, FvHeader->FvLength));
Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Chasel Chiu <chasel.chiu@intel.com> Cc: Amy Chan <amy.chan@intel.com> Cc: Rangasai V Chaganty <rangasai.v.chaganty@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Chasel Chiu <chasel.chiu@intel.com> Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
ArmVirtPkg/ArmVirtQemu: hook NvVarStoreFormattedLib into VariableRuntimeDxe
In spite of both ArmVirtQemu and ArmVirtQemuKernel formatting the variable
store template at build time, link NvVarStoreFormattedLib into
VariableRuntimeDxe via NULL class resolution on both platforms. This lets
us test the depexes implemented in the previous patches.
ArmVirtPkg/PlatformHasAcpiDtDxe: depend on gEfiVariableArchProtocolGuid
PlatformHasAcpiDtDxe consumes the DynamicHii PCD called
"gArmVirtTokenSpaceGuid.PcdForceNoAcpi". The PcdGetBool() library call
terminates in gRT->GetVariable(), in the MdeModulePkg/Universal/PCD/Dxe
driver. Put "gEfiVariableArchProtocolGuid" on PlatformHasAcpiDtDxe's DEPEX
so that we not attempt the call before the PCD driver can successfully
read non-volatile variables.
ArmPlatformPkg/PL031RealTimeClockLib: depend on gEfiCpuArchProtocolGuid
The RealTimeClockLib class is declared under EmbeddedPkg, so that
platforms can provide the internals for the
EmbeddedPkg/RealTimeClockRuntimeDxe driver. In turn the driver produces
the Real Time Clock Arch Protocol, without which UEFI drivers cannot be
dispatched.
The PL031RealTimeClockLib instance calls gDS->SetMemorySpaceAttributes()
in the LibRtcInitialize() public function. This DXE service depends on the
CPU Arch Protocol. Add it to the depex.
ArmPlatformPkg/NorFlashDxe: depend on gEfiCpuArchProtocolGuid
NorFlashFvbInitialize() calls gDS->SetMemorySpaceAttributes() to mark the
varstore flash region as uncached. This DXE service depends on the CPU
Architectural protocol, and the DXE core is allowed to return
EFI_NOT_AVAILABLE_YET if it hasn't dispatched ArmPkg/Drivers/CpuDxe
earlier. Make the dependency explicit.
ArmPlatformPkg/NorFlashDxe: cue the variable driver with NvVarStoreFormatted
The BEFORE depex opcode that we currently use to force ourselves in front
of the variable driver cannot be combined with other depex opcodes.
Replace the depex with TRUE, and signal NvVarStoreFormattedLib through the
installation of "gEdkiiNvVarStoreFormattedGuid".
Platforms that rely on NorFlashDxe to format the variable store (as
opposed to formatting a variable store template through an FDF file, as
part of the build) should hook NvVarStoreFormattedLib into the variable
drivers they use, so that the latter await our cue.
The lazy initialization of the varstore FVB makes no longer sense at this
point:
- "mNorFlashInstanceTemplate.Initialize" is NULL;
- in NorFlashCreateInstance(), we only set Instance->Initialize to
non-NULL -- namely NorFlashFvbInitialize() -- if the FVB stands for the
variable store (see "ContainVariableStorage" / "SupportFvb");
- we call Instance->Initialize() from three places:
- from NorFlashWriteSingleBlock(), which is too late for the variable
read service ("variable write" depends on "variable read");
- from InitializeFvAndVariableStoreHeaders(), but that is only reachable
from NorFlashFvbInitialize(), i.e. recursively from
Instance->Initialize() itself;
- and from FvbRead(), which is never called by the variable driver, only
by the FTW driver. However, the variable driver may read (not write)
the memory-mapped varstore flash chip before the FTW driver is
dispatched.
Therefore the lazy initialization is both superfluous and insufficient.
Initialize the varstore headers eagerly, before we install the FVB
protocol interface.
Some platforms don't format a variable store template at build time;
instead they format the non-volatile varstore flash chip during boot,
dynamically. Introduce NvVarStoreFormattedLib to enable such platforms to
delay the "variable read" service drivers until the platform specific
module(s) report that the variable store has been formatted.
The platform-specific module that performs the formatting during startup
is usually an FVB or MM FVB driver. Under the proposed scheme, it becomes
responsible for installing gEdkiiNvVarStoreFormattedGuid with a NULL
interface in the protocol database. In turn, the platform DSC will hook
NvVarStoreFormattedLib into the variable service driver, to make the
latter wait for the FVB driver. Platforms that need not delay the variable
service driver like this may still use the same FVB driver;
gEdkiiNvVarStoreFormattedGuid will simply be ignored.
ArmPkg/CpuDxe: order CpuDxe after ArmGicDxe via protocol depex
Commit 61a7b0ec634f ("ArmPkg/Gic: force GIC driver to run before CPU arch
protocol driver", 2018-02-06) explains why CpuDxe should be dispatched
after ArmGicDxe.
To implement the ordering, we should use a regular protocol depex rather
than the less flexible AFTER opcode. ArmGicDxe installs
gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid as one
of the last actions on its entry point stack; either of those is OK for
CpuDxe to wait for.
ArmPkg/ArmGicDxe: annotate protocol usage in "ArmGicDxe.inf"
"ArmGicDxe.inf" currently does not document how the protocols in the
[Protocols] section are used. Such comments help us analyze behavior, so
let's add them now.
- gHardwareInterruptProtocolGuid and gHardwareInterrupt2ProtocolGuid are
always produced on the InterruptDxeInitialize() -> (GicV2DxeInitialize()
| GicV3DxeInitialize()) -> InstallAndRegisterInterruptService() call
path.
- gEfiCpuArchProtocolGuid is consumed in the CpuArchEventProtocolNotify()
protocol notify callback. (Technically this is "conditional"; however
the firmware cannot work without architectural protocols, so we can call
it unconditional.)
While at it, drop the gArmGicDxeFileGuid comment from FILE_GUID; we're
going to make that GUID uninteresting soon.
Omap35xxPkg/InterruptDxe: replace CPU Arch Protocol depex with notify
In a later patch, we'll modify the depex of
"ArmPkg/Drivers/CpuDxe/CpuDxe.inf" (currently "AFTER gArmGicDxeFileGuid")
to "gHardwareInterruptProtocolGuid OR gHardwareInterrupt2ProtocolGuid".
Considering platforms that include "ArmPkg/Drivers/CpuDxe/CpuDxe.inf",
there are two classes:
(1) The platform gets its gHardwareInterruptProtocolGuid or
gHardwareInterrupt2ProtocolGuid instance from
"ArmPkg/Drivers/ArmGic/ArmGicDxe.inf". For such platforms, the
upcoming CpuDxe change is not a problem, because commit 61a7b0ec634f
made ArmGicDxe wait for the CPU Arch Protocol with a protocol notify.
(2) The platform gets its hardware interrupt protocol(s) from a different
driver that has a hard depex on the CPU Arch Protocol. The upcoming
CpuDxe change would lead to a loop in the DXE dispatch order.
In the edk2 tree, only "BeagleBoardPkg/BeagleBoardPkg.dsc" falls in class
(2), and the driver in question is "Omap35xxPkg/InterruptDxe". Port (most
of) commit 61a7b0ec634f to it.
Use HandleProtocol() to pass thru a SetImage() call to the
System FMP Protocol that must be on the same handle as the
FMP Protocol.
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>
Uninstall all System FMP Protocols for the current FW device.
If an FMP Protocol for the current FW device is already present,
then install the new System FMP protocol onto the same handle as
the FMP Protocol. Otherwise, install the FMP protocol onto a
new handle.
This supports use cases where multiple capsules for the
same system firmware device are processed on the same
boot of the platform. It guarantees there is at most one
FMP protocol for each system firmware 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>
1. when inf file is binary module, not generate makefile,
so need generate ffs with previous method.
2. generate Ui section maybe override and the string is not
$(MODULE_NAME)
like as:
INF RuleOverride = UI MdeModulePkg/Application/UiApp/UiApp.inf
3. Trim generate incorrect Offset.raw when some vfr not generate .lst
file in Debug directory, Trim get the VFR name with the .c files
replacement.
4. fix some depex file not generate issue
Issue:
genfds-multi-thread create makefile before section file generation,
so it get alignment is zero from empty file. It is incorrect.
solution:
GenSec get section alignment from input file when the input alignment
is zero.
OvmfPkg: remove BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe
BLOCK_MMIO_PROTOCOL and BlockMmioToBlockIoDxe were introduced to OvmfPkg
in March 2010, in adjacent commits b0f5144676fa and efd82c5794ec. 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>
These files are not used by any tool:
BaseTools/Source/Python/Common/DecClassObject.py
BaseTools/Source/Python/Common/DscClassObject.py
BaseTools/Source/Python/Common/FdfClassObject.py
BaseTools/Source/Python/Common/InfClassObject.py
Yonghong Zhu [Sat, 17 Mar 2018 07:25:32 +0000 (15:25 +0800)]
BaseTools: Fix the bug for VOID* pcd max size from component section
When the Pcd defined in components section, its value's size is larger
than the value's size in [pcd] section, it cause build error, because
original code use the size get in [pcd] section as max size.
Yonghong Zhu [Wed, 14 Mar 2018 12:20:23 +0000 (20:20 +0800)]
BaseTools: Fix size override issue for Void* Patchable pcd
when multiple driver link same library, and the drivers override the pcd
to different value in the DSC component section, it cause the pcd size
incorrect.
Yonghong Zhu [Wed, 14 Mar 2018 08:51:04 +0000 (16:51 +0800)]
BaseTools: Fix a bug for Size incorrect of Void* Fixatbuild Pcd
when driver link library and there have pcd override in DSC component
section, in the library autogen file, the pcd's size is incorrect, the
size value is from DSC [pcd] section, but not from the override pcd
value that in the [component] section.
BaseTools: Parse PCD GUID name in FILE statement issue
FDF format as below:
FILE APPLICATION = PCD(PcdToken.PcdCName) {
}
when parse PCD, need get all PCDs from Platform and Packages,
use self.BuildObject[self.Platform, Arch] get some modules is wrong.
so use self.BuildObject[self.Platform, Arch, TargetName, ToolChainTag]
get all modules.
Cc: Dandan Bi <dandan.bi@intel.com> Cc: Jiewen Yao <jiewen.yao@intel.com> Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1 Signed-off-by: Star Zeng <star.zeng@intel.com> Reviewed-by: Dandan Bi <dandan.bi@intel.com>
projects / mirror_edk2.git / log