Currently, only parts of the Header files can be collected which
caused some struct definition can not be found. To solve this issue,
Header files full collection has been added in this file to support
the struct finding.
Cc: Bob Feng <bob.c.feng@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Yuwei Chen <yuwei.chen@intel.com>
Reviewed-by: Bob Feng <bob.c.feng@intel.com>
Copy UefiCpuPkg/ResetVector/Vtf0/Ia16/Real16ToFlat32.asm to
OvmfPkg/Bhyve/ResetVector/Ia16, with one change, as has also been
made in XenResetVector:
- SEC_DEFAULT_CR0: enable cache (bit 30 or CD set to 0)
With the CD bit set to 1, this has the downside on AMD systems of
actually running with the cache disabled, which slows the entire system
to a crawl.
There's no need for this bit to be set in virtualized
environments.
This patch reapplies the change from the freebsd uefi-edk2 repo at
08c00f4e8d
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Peter Grehan <grehan@freebsd.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20201124005733.18107-4-rebecca@bsdio.com>
The current variable policy is allocated by AllocatePool(), which is
boot time only. This means that if you do any variable setting in the
runtime, the policy has been freed. Ordinarily this isn't detected
because freed memory is still there, but when you boot the Linux
kernel, it's been remapped so the actual memory no longer exists in
the memory map causing a page fault.
Fix this by making it AllocateRuntimePool(). For SMM drivers, the
platform DSC is responsible for resolving the MemoryAllocationLib
class to the SmmMemoryAllocationLib instance. In the
SmmMemoryAllocationLib instance, AllocatePool() and
AllocateRuntimePool() are implemented identically. Therefore this
change is a no-op when the RegisterVariablePolicy() function is built
into an SMM driver. The fix affects runtime DXE drivers only.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=3092
Signed-off-by: James Bottomley <jejb@linux.ibm.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
The LzmaUefiDecompressGetInfo() function
[MdeModulePkg/Library/LzmaCustomDecompressLib/LzmaDecompress.c] currently
silently truncates the UINT64 "DecodedSize" property of the compressed
blob to the UINT32 "DestinationSize" output parameter.
If "DecodedSize" is 0x1_0000_0100, for example, then the subsequent memory
allocation (for decompression) will likely succeed (allocating 0x100 bytes
only), but then the LzmaUefiDecompress() function (which re-fetches the
uncompressed buffer size from the same LZMA header into a "SizeT"
variable) will overwrite the buffer.
Catch (DecodedSize > MAX_UINT32) in LzmaUefiDecompressGetInfo() at once.
This should not be a practical limitation. (The issue cannot be fixed for
32-bit systems without spec modifications anyway, given that the
"OutputSize" output parameter of
EFI_GUIDED_SECTION_EXTRACTION_PROTOCOL.ExtractSection() has type UINTN,
not UINT64.)
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1816
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119115034.12897-2-lersek@redhat.com>
The DXE Core sets up a protocol notify function in its entry point, for
instances of the Firmware Volume Block2 Protocol:
DxeMain() [DxeMain/DxeMain.c]
FwVolDriverInit() [FwVol/FwVol.c]
Assume that a 3rd party UEFI driver or application installs an FVB
instance, with crafted contents. The notification function runs:
NotifyFwVolBlock() [FwVol/FwVol.c]
installing an instance of the Firmware Volume 2 Protocol on the handle.
(Alternatively, assume that a 3rd party application calls
gDS->ProcessFirmwareVolume(), which may also produce a Firmware Volume 2
Protocol instance.)
The EFI_FIRMWARE_VOLUME2_PROTOCOL.ReadSection() member performs "a
depth-first, left-to-right search algorithm through all sections found in
the specified file" (quoting the PI spec), as follows:
FvReadFileSection() [FwVol/FwVolRead.c]
GetSection() [SectionExtraction/CoreSectionExtraction.c]
FindChildNode() [SectionExtraction/CoreSectionExtraction.c]
FindChildNode() // recursive call
FindChildNode() is called recursively for encapsulation sections.
Currently this recursion is not limited. Introduce a new PCD
(fixed-at-build, or patchable-in-module), and make FindChildNode() track
the section nesting depth against that PCD.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1743
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119105340.16225-3-lersek@redhat.com>
FindChildNode() has two callers: GetSection(), and FindChildNode() itself.
- At the GetSection() call site, a positive (i.e., nonzero)
SectionInstance is passed. This is because GetSection() takes a
zero-based (UINTN) SectionInstance, and then passes
Instance=(SectionInstance+1) to FindChildNode().
- For reaching the recursive FindChildNode() call site, a section type
mismatch, or a section instance mismatch, is necessary. This means,
respectively, that SectionInstance will either not have been decreased,
or not to zero anyway, at the recursive FindChildNode() call site.
Add two ASSERT()s to FindChildNode(), for expressing the (SectionSize>0)
invariant.
In turn, the invariant provides the explanation why, after the recursive
call, a zero SectionInstance implies success. Capture it in a comment.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Philippe Mathieu-Daudé <philmd@redhat.com>
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
Reviewed-by: Philippe Mathieu-Daudé <philmd@redhat.com>
Message-Id: <20201119105340.16225-2-lersek@redhat.com>
When trying to get page table base, if mInternalCr3 is zero, it will use
the page table from CR3, and reflect the page table depth by CR4 LA57 bit.
If mInternalCr3 is non zero, it will use the page table from mInternalCr3
and reflect the page table depth of mInternalCr3 at same time.
In the case of X64, we use m5LevelPagingNeeded to reflect the depth of
the page table. And in the case of IA32, it will not the page table depth
information.
This patch is a bug fix when enable CET feature with 5 level paging.
The SMM page tables are allocated / initialized in PiCpuSmmEntry().
When CET is enabled, PiCpuSmmEntry() must further modify the attribute of
shadow stack pages. This page table is not set to CR3 in PiCpuSmmEntry().
So the page table base address is set to mInternalCr3 for modifty the
page table attribute. It could not use CR4 LA57 bit to reflect the
page table depth for mInternalCr3.
So we create a architecture-specific implementation GetPageTable() with
2 output parameters. One parameter is used to output the page table
address. Another parameter is used to reflect if it is 5 level paging
or not.
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3015
Signed-off-by: Sheng Wei <w.sheng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Rahul Kumar <rahul1.kumar@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Eric Dong <eric.dong@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3003
There is a plan to make MD5 disable as default.
The new MACRO ENABLE_MD5_DEPRECATED_INTERFACES
would be introduced to enable MD5. Make the
definition ahead of the change to avoid build
error after the MACRO changed.
1. Add the NetworkBuildOptions.dsc.inc to define
the MACRO for build (support: GCC, INTEL, MSFT and
RVCT)
2. Add the BuildOption file to Network.dsc.inc
Cc: Maciej Rabeda <maciej.rabeda@linux.intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Siyuan Fu <siyuan.fu@intel.com>
Signed-off-by: Zhichao Gao <zhichao.gao@intel.com>
Message-Id: <20201112055558.2348-5-zhichao.gao@intel.com>
[lersek@redhat.com: clean up comments in "NetworkBuildOptions.dsc.inc"]
[lersek@redhat.com: hoist "BuildOptions" above "Components" in
"Network.dsc.inc" for bug compat with edk2-platforms]
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Siyuan Fu <siyuan.fu@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=3074
* Fix offset of LinkLayerControlAndStatus in the
CXL_1_1_LINK_CAPABILITY_STRUCTURE structure
* Fix offset of LinkLayerAckTimerControl in the
CXL_1_1_LINK_CAPABILITY_STRUCTURE structure
* Fix offset of LinkLayerDefeature in
the CXL_1_1_LINK_CAPABILITY_STRUCTURE structure
* Add CXL_11_SIZE_ASSERT() macro to verify the size of
a register layout structure at compile time and use
it to verify the sizes of the CXL 1.1 register structures.
* Add CXL_11_OFFSET_ASSERT() macro to verify the offset of
fields in a register layout structure at compiler time and
use it to verify the offset of fields in CXL 1.1
register structures.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Zhiguang Liu <zhiguang.liu@intel.com>
Cc: Ashraf Javeed <ashraf.javeed@intel.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Zhiguang Liu <zhiguang.liu@intel.com>
Reviewed-by: Ashraf Javeed <ashraf.javeed@intel.com>
Current FSP rebasing script SplitFspBin.py has support for both
PE32 and PE32+ image formats. However, while updating the ImageBase
field in the image header, it always assumed the ImageBase field is
32bit long. Since PE32+ image format defined ImageBase as 64bit,
the current script will only update the lower 32bit value and leave
the upper 32bit untouched. It does not work well for PE32+ image
that requires update in the upper 32bit ImageBase field. The
expected behavior is to update the full 64bit field. This patch
implemented this fix.
Signed-off-by: Maurice Ma <maurice.ma@intel.com>
Cc: Chasel Chiu <chasel.chiu@intel.com>
Cc: Nate DeSimone <nathaniel.l.desimone@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Reviewed-by: Chasel Chiu <chasel.chiu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Nate DeSimone <nathaniel.l.desimone@intel.com>
