Rename SmmEndOfS3ResumeProtocolGuid to EndOfS3ResumeGuid as the GUID
may be used to install PPI in future to notify PEI phase code.
The references in UefiCpuPkg are also being updated.
Cc: Jiewen Yao <jiewen.yao@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: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
It is missing to update the prototype of SmmCommunicationCommunicate()
in d1632f694b.
This patch is to add it.
Cc: Dandan Bi <dandan.bi@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: Dandan Bi <dandan.bi@intel.com>
This patch will set the memory pages used for page table as read-only
memory after the paging is setup. CR0.WP must set to let it take into
effect.
A simple page table memory management mechanism, page table pool concept,
is introduced to simplify the page table memory allocation and protection.
It will also help to reduce the potential recursive "split" action during
updating memory paging attributes.
The basic idea is to allocate a bunch of continuous pages of memory in
advance as one or more page table pools, and all future page tables
consumption will happen in those pool instead of system memory. If the page
pool is reserved at the boundary of 2MB page and with same size of 2MB page,
there's no page granularity "split" operation will be needed, because the
memory of new page tables (if needed) will be usually in the same page as
target page table you're working on.
And since we have centralized page tables (a few 2MB pages), it's easier
to protect them by changing their attributes to be read-only once and for
all. There's no need to apply the protection for new page tables any more
as long as the pool has free pages available.
Once current page table pool has been used up, one can allocate another 2MB
memory pool and just set this new 2MB memory block to be read-only instead of
setting the new page tables one page by one page.
Two new PCDs PcdPageTablePoolUnitSize and PcdPageTablePoolAlignment are used
to specify the size and alignment for page table pool. For IA32 processor
0x200000 (2MB) is the only choice for both of them to meet the requirement of
page table pool.
Laszlo (lersek@redhat.com) did a regression test on QEMU virtual platform with
one middle version of this series patch. The details can be found at
https://lists.01.org/pipermail/edk2-devel/2017-December/018625.html
There're a few changes after his work.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@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: Jiewen Yao <jiewen.yao@intel.com>
Move ClearFirst4KPage/IsNullDetectionEnabled definition from DxeIpl.h to
VirtualMemory.h as they are implemented in VirtualMemory.c and only used
in IA32/X64 ARCH.
Cc: Jian J Wang <jian.j.wang@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Stack guard feature makes use of paging mechanism to monitor if there's a
stack overflow occurred during boot.
This patch will check setting of PCD PcdCpuStackGuard. If it's TRUE, DxeIpl
will setup page table and set the page at which the stack base locates to be
NOT PRESENT. If stack is used up and memory access cross into the last page
of it, #PF exception will be triggered.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
Original API InitializeCpuExceptionHandlers is used in DxeMain to initialize
exception handlers but it does not support setting up stack switch required
by Stack Guard feature. Using the new API instead to make sure Stack Guard
feature is applicable to most part of code.
Since this API is called before memory service initialization, there's no
way to call AllocateXxx API to reserve memory. Global variables are used
for this special case. GDT table is reserved at least 2KB which should be
big enough for all current use cases.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Jeff Fan <vanjeff_919@hotmail.com>
Reviewed-by: Jiewen.yao@intel.com
Handle CommSize OPTIONAL case for SmmCommunicate.
And return EFI_ACCESS_DENIED when CommunicationBuffer
is not valid for SMM to access.
Cc: Jiewen Yao <jiewen.yao@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: Jiewen Yao <jiewen.yao@intel.com>
In commit 7eb927db3e ("MdeModulePkg/DxeCore: implement memory protection
policy", 2017-02-24), we added two informative messages with the
InitializeDxeNxMemoryProtectionPolicy() function:
> InitializeDxeNxMemoryProtectionPolicy: applying strict permissions to
> active memory regions
and
> InitializeDxeNxMemoryProtectionPolicy: applying strict permissions to
> inactive memory regions
The messages don't report errors or warnings, thus downgrade their log
masks from DEBUG_ERROR to DEBUG_INFO.
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Ref: https://bugzilla.redhat.com/show_bug.cgi?id=1520485
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
It fixes the warning for loop has empty body [-Werror,-Wempty-body].
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liang Vincent <vincent.liang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
The USED_SIZE FV_EXT_TYPE is introduced by PI 1.6 spec.
The EFI_FIRMWARE_VOLUME_EXT_ENTRY_USED_SIZE_TYPE can be used to find
out how many EFI_FVB2_ERASE_POLARITY bytes are at the end of the FV.
When the FV gets shadowed into memory you only need to copy the used
bytes into memory and fill the rest of the memory buffer with the
erase value.
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: Liming Gao <liming.gao@intel.com>
No need to allocate aligned buffer if FvImage has been
at required alignment.
Then the code logic will be aligned with ProcessFvFile() in
MdeModulePkg/Core/Pei/FwVol/FwVol.c.
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: Liming Gao <liming.gao@intel.com>
The USED_SIZE FV_EXT_TYPE is introduced by PI 1.6 spec.
The EFI_FIRMWARE_VOLUME_EXT_ENTRY_USED_SIZE_TYPE can be used to find
out how many EFI_FVB2_ERASE_POLARITY bytes are at the end of the FV.
When the FV gets shadowed into memory you only need to copy the used
bytes into memory and fill the rest of the memory buffer with the
erase value.
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: Liming Gao <liming.gao@intel.com>
Once the paging capabilities were filtered out, there might be some adjacent entries
sharing the same capabilities. It's recommended to merge those entries for the OS
compatibility purpose.
This patch makes use of existing method MergeMemoryMap() to do it. This is done by
simply turning this method from static to extern, and call it after filter code.
This patch is related to an issue described at
https://bugzilla.tianocore.org/show_bug.cgi?id=753
This patch is also passed test of booting follow OSs:
Windows 10
Windows Server 2016
Fedora 26
Fedora 25
Cc: Jiewen Yao <jiewen.yao@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: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Some OSs will treat EFI_MEMORY_DESCRIPTOR.Attribute as really
set attributes and change memory paging attribute accordingly.
But current EFI_MEMORY_DESCRIPTOR.Attribute is assigned by
value from Capabilities in GCD memory map. This might cause
boot problems. Clearing all paging related capabilities can
workaround it. The code added in this patch is supposed to
be removed once the usage of EFI_MEMORY_DESCRIPTOR.Attribute
is clarified in UEFI spec and adopted by both EDK-II Core and
all supported OSs.
Laszlo did a thorough test on OVMF emulated platform. The details
can be found at
https://bugzilla.tianocore.org/show_bug.cgi?id=753#c10
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
In the method DumpGuardedMemoryBitmap() and SetAllGuardPages(), the code
didn't check if the global mMapLevel is legal value or not, which leaves
a logic hole causing potential array overflow in code followed.
This patch adds sanity check before any array reference in those methods.
Cc: Wu Hao <hao.a.wu@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Wu Hao <hao.a.wu@intel.com>
The coding style requires that header files must be also added in module's inf
file, as long as they're included by c files. This patch will fix this issue.
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
The build error is introduced by following check in:
2930ef9809235a4490c8
The Visual Studio older than 2015 doesn't support constant integer
in binary format (0bxxx). This patch changes them to BIT macro to
fix it. This patch also cleans up coding style about unmatched
comment for return value.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Bi Dandan <dandan.bi@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>
Following check-in caused this issue:
2930ef9809
This issue is caused by assigning incorrect value to PoolHdr.Size
if the requested size is more than MAX_POOL_SIZE, because the SMM
core will actually allocate page memory instead of pool memory in
this situation.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Wu Hao <hao.a.wu@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>
Reviewed-by: Wu Hao <hao.a.wu@intel.com>
Tested-by: Wu Hao <hao.a.wu@intel.com>
This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.
This feature is controlled by three PCDs:
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType
BIT2 and BIT3 of PcdHeapGuardPropertyMask can be used to enable or disable
memory guard for SMM page and pool respectively. PcdHeapGuardPoolType and/or
PcdHeapGuardPageType are used to enable or disable guard for specific type
of memory. For example, we can turn on guard only for EfiRuntimeServicesCode
and EfiRuntimeServicesData by setting the PCD with value 0x60.
Pool memory is not ususally integer multiple of one page, and is more likely
less than a page. There's no way to monitor the overflow at both top and
bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control
how to position the head of pool memory so that it's easier to catch memory
overflow in memory growing direction or in decreasing direction.
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@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>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
This feature makes use of paging mechanism to add a hidden (not present)
page just before and after the allocated memory block. If the code tries
to access memory outside of the allocated part, page fault exception will
be triggered.
This feature is controlled by three PCDs:
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPropertyMask
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPoolType
gEfiMdeModulePkgTokenSpaceGuid.PcdHeapGuardPageType
BIT0 and BIT1 of PcdHeapGuardPropertyMask can be used to enable or disable
memory guard for page and pool respectively. PcdHeapGuardPoolType and/or
PcdHeapGuardPageType are used to enable or disable guard for specific type
of memory. For example, we can turn on guard only for EfiBootServicesData
and EfiRuntimeServicesData by setting the PCD with value 0x50.
Pool memory is not ususally integer multiple of one page, and is more likely
less than a page. There's no way to monitor the overflow at both top and
bottom of pool memory. BIT7 of PcdHeapGuardPropertyMask is used to control
how to position the head of pool memory so that it's easier to catch memory
overflow in memory growing direction or in decreasing direction.
Note1: Turning on heap guard, especially pool guard, will introduce too many
memory fragments. Windows 10 has a limitation in its boot loader, which
accepts at most 512 memory descriptors passed from BIOS. This will prevent
Windows 10 from booting if heap guard is enabled. The latest Linux
distribution with grub boot loader has no such issue. Normally it's not
recommended to enable this feature in production build of BIOS.
Note2: Don't enable this feature for NT32 emulation platform which doesn't
support paging.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Suggested-by: Ayellet Wolman <ayellet.wolman@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>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Heap guard feature needs paging to work properly. 64-bit BIOS uses
PcdDxeIplBuildPageTables to control the page table setup. 32-bit BIOS
has to check heap guard feature to decide enabling paging or not.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@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>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=765
The UEFI Specification Boot Services chapter, StartImage() service,
EFF 1.10 Extension requires extra calls to ConnectController()
if a UEFI Driver produces handles. The DXE Core is performing these
extra calls to ConnectController() without evaluating the ImageType.
A filter is added to not make extra calls to ConnectController()
if the ImageType is EFI_IMAGE_SUBSYSTEM_EFI_APPLICATION.
Without this filter, extra calls to ConnectController() may be
performed by UEFI Applications or a UEFI Shell Applications that
also call ConnectController().
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Make the comments align with the function.
And add some missing function comments.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
This is the regression issue. After apply CalculateCrc32(), the parameter
check is missing.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Wu Hao A <hao.a.wu@intel.com>
Install EdkiiSmmEndOfS3ResumeProtocol when S3 resume finished.
S3ResumePei will send S3 resume finished event to SmmCore through
communication buffer.
V2 change:
None.
V3 change:
1. Uninstall the protocol right after install it to avoid run out of memory.
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Eric Dong <eric.dong@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
One of issue caused by enabling NULL pointer detection is that some PCI
device OptionROM, binary drivers and binary OS boot loaders may have NULL
pointer access bugs, which will prevent BIOS from booting and is almost
impossible to fix. BIT7 of PCD PcdNullPointerDetectionPropertyMask is used
as a workaround to indicate BIOS to disable NULL pointer detection right
after event gEfiEndOfDxeEventGroupGuid, and then let boot continue.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ayellet Wolman <ayellet.wolman@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@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>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
NULL pointer detection is done by making use of paging mechanism of CPU.
During page table setup, if enabled, the first 4-K page (0-4095) will be
marked as NOT PRESENT. Any code which unintentionally access memory between
0-4095 will trigger a Page Fault exception which warns users that there's
potential illegal code in BIOS.
This also means that legacy code which has to access memory between 0-4095
should be cautious to temporarily disable this feature before the access
and re-enable it afterwards; or disalbe this feature at all.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Ayellet Wolman <ayellet.wolman@intel.com>
Suggested-by: Ayellet Wolman <ayellet.wolman@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>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
FV3 HOB was introduced by new (>= 1.5) PI spec, it is intended to
be used to propagate PEI-phase FV authentication status to DXE.
This patch is to update PeiCore to build FV3 HOB with the
authentication status and DxeCore to get the authentication
status from FV3 HOB when producing FVB Protocol.
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: Liming Gao <liming.gao@intel.com>
Commit 8932679df5 adds an ASSERT for
checking NULL pointer dereference.
The ASSERT added here is for addressing a false positive NULL pointer
dereference issue raised from static analysis.
This commit adds comments to clarify the reason for using ASSERT as the
check.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@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>
The debug messages can help developer to know the pre-memory
allocation usage.
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: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=695
Within function CoreRestoreTpl(), left shift a negative value -2 is used
in:
"while (((-2 << NewTpl) & gEventPending) != 0) {"
which involves undefined behavior.
According to the C11 spec, Section 6.5.7:
> 4 The result of E1 << E2 is E1 left-shifted E2 bit positions; vacated
> bits are filled with zeros. If E1 has an unsigned type, the value
> of the result is E1 * 2^E2 , reduced modulo one more than the
> maximum value representable in the result type. If E1 has a signed
> type and nonnegative value, and E1 * 2^E2 is representable in the
> result type, then that is the resulting value; otherwise, the
> behavior is undefined.
This commit refines the code logic to avoid left shifting the negative
value.
Cc: Steven Shi <steven.shi@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Paolo Bonzini <pbonzini@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Follow PI 1.6 spec to support FFS_ATTRIB_DATA_ALIGNMENT_2 for
FFS alignment extended to support maximum 16MB.
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: Liming Gao <liming.gao@intel.com>
Change since v4: Revise the patch based on V4 sent by Amit Kumar
1) Only return the corresponding protocol interface in *Interface
if the return status is EFI_SUCCESS or EFI_ALREADY_STARTED.
2) Interface is returned unmodified for all error conditions except
EFI_UNSUPPORTED and EFI_ALREADY_STARTED, NULL will be returned in
*Interface when EFI_UNSUPPORTED and Attributes is not
EFI_OPEN_PROTOCOL_TEST_PROTOCOL, the protocol interface will be
returned in *Interface when EFI_ALREADY_STARTED.
Change since v3:
1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL
and Inteface = NULL case. [Reported by:star.zeng at intel.com]
Change Since v2:
1) Modified to use EFI_ERROR to get status code
Change since v1:
1) Fixed typo protocal to protocol
2) Fixed coding style
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Amit Kumar <amit.ak@samsung.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Gabriel Somlo <gsomlo@gmail.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Amit Kumar <amit.ak@samsung.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Tested-by: Gabriel Somlo <gsomlo@gmail.com>
From GCD perspective, its SetMemorySpaceAttributes() method doesn't accept page
related attributes. That means users cannot use it to change page attributes,
and have to turn to CPU arch protocol to do it, which is not be allowed by PI
spec.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Suggested-by: 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>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Support pre memory page allocation.
Support FreePages.
Allocation made prior to permanent memory will be
migrated to permanent memory and the HOB updated.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ruiyu Ni <Ruiyu.Ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
When double free pages by FreePages() or allocate allocated pages by
AllocatePages() with AllocateAddress type, the code will print debug
message "ConvertPages: Incompatible memory types", but the debug
message is not very obvious for the error paths by FreePages() or
AllocatePages().
Refer https://lists.01.org/pipermail/edk2-devel/2017-August/013075.html
for the discussion.
This patch is to enhance the debug message for the error paths by
FreePages() or AllocatePages.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=667
reported there is double free pages on LoadImage failure path.
CoreLoadPeImage()
...
return EFI_SUCCESS;
Done:
//
// Free memory.
//
if (DstBufAlocated) {
CoreFreePages (Image->ImageContext.ImageAddress, Image->NumberOfPages);
}
...
CoreUnloadAndCloseImage()
...
if ((Image->ImageBasePage != 0) && FreePage) {
CoreFreePages (Image->ImageBasePage, Image->NumberOfPages);
}
...
This patch is to follow the suggestion at
https://lists.01.org/pipermail/edk2-devel/2017-August/013112.html
to set Image->ImageContext.ImageAddress and Image->ImageBasePage to 0
after the free in CoreLoadPeImage().
Cc: Liming Gao <liming.gao@intel.com>
Cc: Andrew Fish <afish@apple.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
If the EFI_SEC_HOB_DATA_PPI is in the list of PPIs passed to the PEI
entry point, the PEI Foundation will call the GetHobs() member
function and install all HOBs returned into the HOB list. It does
this after installing all PPIs passed from SEC into the PPI database
and before dispatching any PEIMs.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
InstallPpi() will be used for normal PPI in PPI list from SEC,
and NotifyPpi() will be used for notification PPI in PPI list from SEC.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
The patch fixes two kinds of bugs in DxeCore that accesses memory
which might be freed or owned by other modules.
The two bugs don't cause functionality issue.
1. CoreValidateHandle() checks whether the handle is valid by
validating its signature. The proper way is to check whether
the handle is in the handle database.
2. CoreDisconnectControllersUsingProtocolInterface() and
CoreOpenProtocol() de-reference Link pointer which is
already freed. The proper way is to not de-reference the pointer.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
There is a case that ExtractGuidedSectionGetInfo return 0 for
ScratchBufferSize and ScratchBuffer will be NULL, after AllocatePool
fails to allocate buffer for AllocatedOutputBuffer, the code will
call FreePool (ScratchBuffer), but ScratchBuffer == NULL.
This patch is to only free ScratchBuffer when it is not NULL.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Change since v3:
1) Fixed issue when Attributes = EFI_OPEN_PROTOCOL_TEST_PROTOCOL
and Inteface = NULL case. [Reported by:star.zeng at intel.com]
Change Since v2:
1) Modified to use EFI_ERROR to get status code
Change since v1:
1) Fixed typo protocal to protocol
2) Fixed coding style
Modified source code to update Interface as per spec.
1) In case of Protocol is un-supported, interface should be returned NULL.
2) In case of any error, interface should not be modified.
3) In case of Test Protocol, interface is optional.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Amit Kumar <amit.ak@samsung.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Current code is using debug message like below for
InstallProtocolInterface.
InstallProtocolInterface: XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX XXX
User could not know whether the installation is failed or not by the
debug message, for example, the code below does not initialize Handle
before calling InstallProtocolInterface, EFI_INVALID_PARAMETER will be
returned.
EFI_HANDLE Handle;
Status = gBS->InstallProtocolInterface (
&Handle,
&XXX,
EFI_NATIVE_INTERFACE,
XXX
);
This patch is to add additional debug message if the installation
is failed and specific debug message for the case that the input
handle is invalid.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Return EFI_INVALID_PARAMETER in LocateProtocol for Protocol==NULL to
follow UEFI 2.7 spec
PiSmmCore is also updated as the EFI_SMM_SYSTEM_TABLE2.SmmLocateProtocol
is reusing the definition of EFI_LOCATE_PROTOCOL.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=601
When installing configuration table and the original
gDxeCoreST->ConfigurationTable[] buffer happen to be not big enough to
add a new table, the CoreInstallConfigurationTable() enter the branch
of line 113 in InstallConfigurationTable.c to free the old
gDxeCoreST->ConfigurationTable[] buffer and allocate a new bigger one.
The problem happens at line 139 CoreFreePool(), which is to free the
old gDxeCoreST->ConfigurationTable[] buffer. The CoreFreePool()'s
behavior is to free the buffer firstly, then call the
InstallMemoryAttributesTableOnMemoryAllocation (PoolType) to update
the EfiRuntimeServices type memory info, the
CoreInstallConfigurationTable() will be re-entered by CoreFreePool()
in its calling stack, then use-after-free read error will happen at
line 59 of InstallConfigurationTable.c and use-after-free write error
will happen at line 151 and 152 of InstallConfigurationTable.c.
The patch is to update System table to the new table pointer before
calling CoreFreePool() to free the old table.
The case above is in DxeCore, but not in PiSmmCore.
The change in PiSmmCore is to be consistent with DxeCore.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Steven Shi <steven.shi@intel.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Steven Shi <steven.shi@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=568
Use fixed data type in data structure and make the structure
be natural aligned.
Without this update, the code must assume DXE and SMM are using
same data type (same size of UINTN), but it may be not true at
some case, for example, after standalone SMM feature is enabled.
With this update, the data structure will be phase independent
and convenient for consumer to parse the data.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=569
The PdbStringOffset should be set to 0 for no PDB case,
then SmiHandlerProfileInfo can use it to know whether
there is PCD info or not.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=530
In DumpSmiChildContext() of SmiHandlerProfile.c and
SmiHandlerProfileInfo.c, the return buffer from
ConvertDevicePathToText() should be freed after used.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
SmramBase should be got from mLMFAConfigurationTable.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This solution is equivalent to DXE core.
AllocatePool() allocates POOL_TAIL after the buffer.
This POOL_TAIL is checked at FreePool().
If the there is buffer overflow, the issue can be caught at FreePool().
This patch could also handle the eight-byte aligned allocation
requirement. The discussion related to the eight-byte aligned
allocation requirement is at
https://lists.01.org/pipermail/edk2-devel/2017-April/009995.html.
According to the PI spec (Vol 4, Section 3.2 SmmAllocatePool()):
The SmmAllocatePool() function ... All allocations are eight-byte aligned.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Hao Wu <hao.a.wu@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
For function SplitRecord() in file PropertiesTable.c, there is a
potential subtract underflow case for line:
return TotalNewRecordCount - 1;
However, such case will not happen since the logic in function
SplitTable() ensure that when calling SplitRecord(), the variable
'TotalNewRecordCount' will not be zero when performing the subtraction.
It will be handled in the previous if statement:
if (MaxSplitRecordCount == 0) {
CopyMem (NewRecord, OldRecord, DescriptorSize);
return 0;
}
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
This commit makes sure that in function CoreStartImage(), module
variable 'mCurrentImage' is restored to the current start image context
on all code paths.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=442
PcdExpression used in INF to control PCD and Source is unsupported feature.
Current sample usage in module INF brings confuse.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Issue reported at bugzillar 445.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
The EFI_IMAGE_MACHINE_TYPE_SUPPORTED() macro is abused in the PeiCore
code to decide whether the system we are compiling for can deal with
executable code being copied elsewhere and executed from there.
As stated in the comment, this is fundamentally a property of the compiler
target, and so this should be made dependent on MDE_CPU_xxx preprocessor
defines, and not on whether or not the runtime target can deal with
PE/COFF images of a certain machine type.
On X86/IA32, this mostly boils down to the same thing, but not on other
architectures, so let's clean this up.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Currently, the PE/COFF image memory protection code uses the same code
paths for protecting and unprotecting an image. This is strange, since
unprotecting an image involves a single call into the CPU arch protocol
to clear the permission attributes of the entire range, and there is no
need to parse the PE/COFF headers again.
So let's store the ImageRecord entries in a linked list, so we can find
it again at unprotect time, and simply clear the permissions.
Note that this fixes a DEBUG hang on an ASSERT() that occurs when the
PE/COFF image fails to load, which causes UnprotectUefiImage() to be
invoked before the image is fully loaded.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
UEFI executables that consist of a single read+write+exec PE/COFF section
trigger this message, but such a binary layout isn't actually an error.
The image can be launched alright, only image protection cannot be applied
to it fully.
One example that elicits the message is (some) Linux kernels (with the EFI
stub of course).
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Laszlo Ersek <lersek@redhat.com>
Acked-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
When attempting to perform page allocations using AllocateAddress, we
fail to check whether the entire region is free before splitting the
region. This may lead to memory being leaked further into the routine,
when it turns out that one of the memory map entries intersected by the
region is already occupied. In this case, prior conversions are not rolled
back.
For instance, starting from this situation
0x000040000000-0x00004007ffff [ConventionalMemory ]
0x000040080000-0x00004009ffff [Boot Data ]
0x0000400a0000-0x000047ffffff [ConventionalMemory ]
a failed EfiLoaderData allocation @ 0x40000000 that covers the BootData
region will fail, but leave the first part of the allocation converted,
so we end up with
0x000040000000-0x00004007ffff [Loader Data ]
0x000040080000-0x00004009ffff [Boot Data ]
0x0000400a0000-0x000047ffffff [ConventionalMemory ]
even though the AllocatePages() call returned an error.
So let's check beforehand that AllocateAddress allocations are covered
by a single memory map entry, so that it either succeeds or fails
completely, rather than leaking allocations.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=370
Use GLOBAL_REMOVE_IF_UNREFERENCED for some memory profile global variables,
then their symbols could be removed when memory profile is disabled.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=370
Use GLOBAL_REMOVE_IF_UNREFERENCED for some SMRAM profile global variables,
then their symbols could be removed when SMRAM profile is disabled.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The reason is that we observe that a platform may use same Handler
for different context.
In order to support Unregister such handler, we have to input
context information as well.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Bret Barkelew <Bret.Barkelew@microsoft.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Architectures such as AArch64 may run the OS with 16 KB or 64 KB sized
pages, and for this reason, the UEFI spec mandates a minimal allocation
granularity of 64 KB for regions that may require different memory
attributes at OS runtime.
So make PeiCore's implementation of AllocatePages () take this into
account as well.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Remove the local definitions for the default and runtime page allocation
granularity macros, and switch to the new MdePkg versions.
Note that this replaces a reference to the 'default' version with the
more correct 'runtime' version, but this matters little in practice.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Remove the local definitions for the default and runtime page allocation
granularity macros, and switch to the new MdePkg versions.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
There are cases that the operands of an expression are all with rank less
than UINT64/INT64 and the result of the expression is explicitly cast to
UINT64/INT64 to fit the target size.
An example will be:
UINT32 a,b;
// a and b can be any unsigned int type with rank less than UINT64, like
// UINT8, UINT16, etc.
UINT64 c;
c = (UINT64) (a + b);
Some static code checkers may warn that the expression result might
overflow within the rank of "int" (integer promotions) and the result is
then cast to a bigger size.
The commit refines codes by the following rules:
1). When the expression is possible to overflow the range of unsigned int/
int:
c = (UINT64)a + b;
2). When the expression will not overflow within the rank of "int", remove
the explicit type casts:
c = a + b;
3). When the expression will be cast to pointer of possible greater size:
UINT32 a,b;
VOID *c;
c = (VOID *)(UINTN)(a + b); --> c = (VOID *)((UINTN)a + b);
4). When one side of a comparison expression contains only operands with
rank less than UINT32:
UINT8 a;
UINT16 b;
UINTN c;
if ((UINTN)(a + b) > c) {...} --> if (((UINT32)a + b) > c) {...}
For rule 4), if we remove the 'UINTN' type cast like:
if (a + b > c) {...}
The VS compiler will complain with warning C4018 (signed/unsigned
mismatch, level 3 warning) due to promoting 'a + b' to type 'int'.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
This PCD holds the address mask for page table entries when memory
encryption is enabled on AMD processors supporting the Secure Encrypted
Virtualization (SEV) feature.
The mask is applied when creating page tables.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Cc: Brijesh Singh <brijesh.singh@amd.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Leo Duran <leo.duran@amd.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This implements a DXE memory protection policy that ensures that regions
that don't require executable permissions are mapped with the non-exec
attribute set.
First of all, it iterates over all entries in the UEFI memory map, and
removes executable permissions according to the configured DXE memory
protection policy, as recorded in PcdDxeNxMemoryProtectionPolicy.
Secondly, it sets or clears the non-executable attribute when allocating
or freeing pages, both for page based or pool based allocations.
Note that this complements the image protection facility, which applies
strict permissions to BootServicesCode/RuntimeServicesCode regions when
the section alignment allows it. The memory protection configured by this
patch operates on non-code regions only.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
In preparation of adding memory permission attribute management to
the pool allocator, split off the locking of the pool metadata into
a separate lock. This is an improvement in itself, given that pool
allocations can only interfere with the page allocation bookkeeping
if pool pages are allocated or released. But it is also required to
ensure that the permission attribute management does not deadlock,
given that it may trigger page table splits leading to additional
page tables being allocated.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Ensure that any memory allocated for PE/COFF images is identifiable as
a boot services code region, so that we know it requires its executable
permissions to be preserved when we tighten mapping permissions later on.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Instead of assuming that a PE/COFF section of type EFI_IMAGE_SCN_CNT_CODE
can always be mapped read-only, classify a section as a code section only
if it has the executable attribute set and the writable attribute cleared.
This adheres more closely to the PE/COFF spec, and avoids issues with
Linux OS loaders that may consist of a single read/write/execute section.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
1) SmmCore maintains the root SMI handler and NULL SMI handler
database.
2) SmmCore consumes PcdSmiHandlerProfilePropertyMask to decide
if SmmCore need support SMI handler profile.
If SMI handler profile is supported, the SmmCore installs
SMI handler profile protocol and SMI handler profile
communication handler.
3) SMI handler profile protocol will record the hardware SMI
handler profile registered by SmmChildDispatcher.
4) SMI handler profile communication handler will return all
SMI handler profile info (NULL SMI handler, GUID SMI handler,
and hardware SMI handler)
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
If the UEFI image is page aligned, the image code section is set to read
only and the image data section is set to non-executable.
1) This policy is applied for all UEFI image including boot service driver,
runtime driver or application.
2) This policy is applied only if the UEFI image meets the page alignment
requirement.
3) This policy is applied only if the Source UEFI image matches the
PcdImageProtectionPolicy definition.
4) This policy is not applied to the non-PE image region.
The DxeCore calls CpuArchProtocol->SetMemoryAttributes() to protect
the image. If the CpuArch protocol is not installed yet, the DxeCore
enqueues the protection request. Once the CpuArch is installed, the
DxeCore dequeues the protection request and applies policy.
Once the image is unloaded, the protection is removed automatically.
The UEFI runtime image protection is teared down at ExitBootServices(),
the runtime image code relocation need write code segment at
SetVirtualAddressMap(). We cannot assume OS/Loader has taken over
page table at that time.
NOTE: It is per-requisite that code section and data section
should not be not merged. That is same criteria for SMM/runtime driver.
We are not able to detect during BIOS boot, because
we can only get LINK warning below:
"LINK : warning LNK4254: section '.data' (C0000040) merged into
'.text' (60000020) with different attributes"
But final attribute in PE code section is same.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
If GUIDED section authentication has EFI_AUTH_STATUS_NOT_TESTED, its
matched extraction ppi may not be installed. So, don't cache its data.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
When PEIM is security violation, its matched extraction ppi may not be
installed. So, its PeimNeedingDispatch will still reset to TRUE.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
When gDS->SetMemorySpaceCapabilities() is called,
current DXE core will sync all GCD attributes to memory map
attributes, including RUNTIME attributes.
It is wrong, because RUNTIME attributes should be set for
runtime memory only.
This fix clears the RUNTIME attributes before convert to UEFI
memory map. So that the UEFI memory map is good after
gDS->SetMemorySpaceCapabilities() is called.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
If a BaseAddress of NULL is passed into DXE Core services
CoreAllocateIoSpace() or CoreAllocateMemorySpace(), and
DEBUG() messages are enabled, then a NULL pointer reference
is made. The parameter check for BaseAddress is performed
in the function CoreAllocateSpace() after the DEBUG()
messages. A check is added in the DEBUG() messages to
prevent the NULL pointer reference.
This issue was found with PI SCTs with DEBUG messages
enabled in the DXE Core.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@Intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
PiSmmIpl records LoadModuleAtFixAddressSmramBase in LMFAConfigurationTable.
Update PiSmmCore to directly get the address from this system table.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Allocate the additional Smram range to describe the reserved smram for
SMM core and driver when LMFA feature is enabled.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
https://bugzilla.tianocore.org/show_bug.cgi?id=278
Zero memory address or zero number pages are invalid to SmmFreePages().
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
EFI_PAGES_TO_SIZE only handles UINTN, so we use EfiPagesToSize
to handle UINT64.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Current memory attribute table implementation will only mark PE code
to be EfiRuntimeServicesCode, and mark rest to be EfiRuntimeServicesData.
However, there might be a case that a SMM code wants to allocate
EfiRuntimeServicesCode explicitly to let page table protect this region
to be read only. It is unsupported.
This patch enhances the current solution so that MemoryAttributeTable
does not touch non PE image record.
Only the PE image region is forced to be EfiRuntimeServicesCode for
code and EfiRuntimeServicesData for data.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
PiSmmCore supports page level protection based upon the Memory Type
(EfiRuntimeServicesCode/EfiRuntimeServicesData) and PE image.
However, the Memory Type information is ignored in AllocatePool().
If a caller calls AllocatePool with EfiRuntimeServicesCode,
the final memory is still allocated as EfiRuntimeServicesData.
This patch supports AllocatePool with EfiRuntimeServicesCode.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Add the comments to describe Free and Allocated SMRAM are added separately.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Make SetPeiServicesTablePointer() earlier than ProcessLibraryConstructorList()
so the constructor() function can get the correct pei service table pointer.
https://bugzilla.tianocore.org/show_bug.cgi?id=238
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
gSmmCorePrivate->CommunicationBuffer and gSmmCorePrivate->BufferSize locate at
runtime memory region. That means they could be modified by non-SMM code during
runtime.
We should cache them into SMM local variables before we verify them. After
verification, we should use the cached ones directly instead of the ones in
gSmmCorePrivate.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
The SMM memory attribute table concept is similar to UEFI
memory attribute table.
The new file MdeModulePkg/Core/PiSmmCore/MemoryAttributesTable.c
and the new code in MdeModulePkg/Core/PiSmmCore/Page.c
are based on the algorithms and implementation from
MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
and MdeModulePkg/Core/Dxe/Mem/Page.c.
These new components are based on the Memory Attributes Table
feature from the UEFI Specification and the existing DXE Core
implementation that supports that feature.
This SMM MemoryAttributes table is produced at SmmEndOfDxe event.
So that the consumer (PiSmmCpu) may consult this table
to set memory attribute in page table.
This patch also installs LoadedImage protocol to SMM
protocol database, so that the SMM image info can be
got easily to construct the PiSmmMemoryAttributes table.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
PeiServicesAllocatePages () will output sizeof (EFI_PHYSICAL_ADDRESS) value.
IdtTableForX64 is sizeof (UINTN) local variable. It will overwrite other local
variable.
This issue is found when we dump BaseOfStack value.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Dump new stack base and size information could help developer to narrow down
stack crash issue.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Instead of comparing a GUID with gZeroGuid via the CompareGuid API, the
commit uses the IsZeroGuid API to check if the given GUID is a zero GUID.
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Feng Tian <feng.tian@Intel.com>
Code logic ensures that the pointer 'DriverInfoData' will not be NULL when
it is used.
Add ASSERT as warning for case that will not happen.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
- abstrated to abstracted
- accessibla to accessible
- addres to address
- apropriate to appropriate
- arry to array
- availabe to available
- avaliable to available
- becasue to because
- correponding to corresponding
- etablished to established
- exeuction to execution
- extensiable to extensible
- fileds to fields
- loadding to loading
- ptototypes to prototypes
- prococol protocol
- requried to required
- resoruce to resource
- runing to running
- uild to build
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Giri P Mudusuru <giri.p.mudusuru@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Switch all users of ArmLib that depend on the MMU routines to the new,
separate ArmMmuLib. This needs to occur in one go, since the MMU
routines are removed from ArmLib build at the same time, to prevent
conflicting symbols.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Acked-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Code logic ensures that both pointers 'DriverInfoData' and 'AllocInfoData'
will not be NULL when they are used.
Add ASSERTs as warning for cases that will not happen.
Cc: Star Zeng <star.zeng@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
1. Produce SMM memory profile protocol.
2. Consume PcdMemoryProfilePropertyMask to support disable recording
at the start.
3. Consume PcdMemoryProfileDriverPath to control which drivers need
memory profile data.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
1. Implement include GetRecordingState/SetRecordingState/Record for
memory profile protocol.
2. Consume PcdMemoryProfilePropertyMask to support disable recording
at the start.
3. Consume PcdMemoryProfileDriverPath to control which drivers need
memory profile data.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
PI specification Vol 4 - SMM does not have any limitation of BASE_4GB for SMM.
So we should replace BASE_4GB check with MAX_ADDRESS check to make sure
the SMM memory is accessible by SMM Core.
Cc: Jeff Fan <jeff.fan@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
The BaseTools/Scripts/ConvertMasmToNasm.py script was used to convert
Ia32/IdtVectorAsm.asm to Ia32/IdtVectorAsm.nasm
Note: Manually updated code storing @VectorTemplateBase address
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jordan Justen <jordan.l.justen@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Star Zeng <star.zeng@intel.com>
PeiCore EntryPoint library _ModuleEntryPoint() will call PeiCore(), then call
CpuDeadLoop (). When NORETURN is added for PeiCore(), MSVC compiler will report
warning C4702: unreachable code for CpuDeadLoop (). And, the warning is treated
as error and cause build break. DxeMain() has the similar issue.
edk2 uses EntryPoint library to wrap every module entry point function except
for SEC. The module entry point is still called by _ModuleEntryPoint(). So,
there will be negative impact to add NORETURN for the module entry point.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
This patch adds the NORETURN attribute to functions that transfer to
other phases, along with an UNREACHABLE() call at the end to avoid
false warnings.
DxeIpl has been excluded as its main function returns a status.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Marvin Haeuser <Marvin.Haeuser@outlook.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
According to PI specification, EndOfDxe Event should be signaled before
DxeSmmReadyToLock protocol installation. This update is ASSERT if EndOfDxe
Event is not signaled when DxeSmmReadyToLock protocol installed. And do
REPORT_STATUS_CODE() also.
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jeff Fan <jeff.fan@intel.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
PI1.4a spec added "For S3 resume boot modes DXE IPL must be
prepared to execute without permanent memory installed and
invoke the S3 resume modules."
To follow PI1.4a spec, this patch is to update DxeIpl and
PeiCore to enable S3 resume from temporary memory.
The normal boot path still enforces the permanent memory
requirement.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eugene@hp.com>
Signed-off-by: Star Zeng <star.zeng@intel.com>
Tested-by: Katie Dellaquila <katie.dellaquila@hp.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
FirmwareVolmeInfoPpiNotifyCallback is re-enterable during FV process. Since PrivateData->FVCount increases when processing each sub FVs, need to cache Parent FV count in stack before processing any sub FV.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Chao Zhang <chao.b.zhang@intel.com>
Reviewed-by: Gao Liming <liming.gao@intel.com>
This patches rename CoreGetMemoryMapPropertiesTable to
CoreGetMemoryMapWithSeparatedImageSection.
The reason is that CoreGetMemoryMapPropertiesTable is called
by MemoryAttributesTable.c to get separated PE image section
information.
It is confusing to use *PropertiesTable, because it is NOT
related to PropertiesTable.c
We rename it to avoid confusing.
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Set the ImageContext.Handle and ImageContext.ImageRead() fields so that
PeCoffLoaderRelocateImageExtraAction() can invoke PeCoffLoaderGetImageInfo
or PeCoffLoaderGetPeHeader if desired to obtain additional metadata.
We will use this to create a PeCoffLoaderRelocateImageExtraAction()
implementation that applies boot time strict mapping permissions to
PE/COFF modules.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
This patch enhance SMM memory profile SMM communication by using fixed
SMM communication buffer.
Update PiSmmCore to handle SMRAM_PROFILE_COMMAND_GET_PROFILE_DATA_BY_OFFSET
request.
This is designed to meet Microsoft WSMT table definition on FIXED_COMM_BUFFERS
requirement.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Laszlo Ersek <lersek@redhat.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Regression-tested-by: Laszlo Ersek <lersek@redhat.com>
Use 128 bytes as the start size region to be same to previous one.
64 bytes is small as the first range. On X64 arch, POOL_OVERHEAD
takes 40 bytes, the pool data less than 24 bytes can be fit into
it. But, the real allocation is few that can't reduce its free pool
link list. And, the second range (64~128) has more allocation
that also increases the free pool link list of the first range.
Then, the link list will become longer and longer. When LinkList
check enable in DEBUG tip, the long link list will bring the
additional overhead and bad performance. Here is the performance
data collected in our X64 platform with DEBUG enable.
64 byte: 22 seconds in BDS phase
128 byte: 19.6 seconds in BDS phase
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
It can improve profile performance, especially when
PcdMemoryProfileMemoryType configured without EfiBootServicesData.
CoreUpdateProfile() can return quickly, but not depend on the further
code to find the buffer not recorded and then return.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The patch uses CoreAcquireLockOrFail() instead of
CoreAcquireProtocolLock() in CoreLocateProtocol() to avoid
assertion when CoreLocateProtocol() is called with the
protocol database locked.
The issue was found when changing PcdDebugPrintErrorLevel to
enable page/pool allocation debug message.
Nt32 platform hangs immediately after DxeCore is loaded.
Investigation shows the following calling stacks:
DxeCore entry point (Install a certain protocol)
0 DxeCore::CoreInstallProtocolInterface // Protocol DB is locked
1 DxeCore::AllocatePool
2 PeiDxeDebugLibReportStatusCode::DebugPrint
3 DxeReportStatusCodeLib::ReportStatusCodeEx // <-------------------|
4 DxeReportStatusCodeLib::InternalGetReportStatusCode |
5 DxeCore::LocateProtocol(StatusCodeRuntimeProtocol) |
// Assertion when locking Protocol DB 2nd time |
6 DxeCore::CoreAcquireProtocolLock |
7 PeiDxeDebugLibReportStatusCode::DebugAssert |
8 DxeReportStatusCodeLib::ReportSatusCodeEx // loop begins ---------
In frame #6 the assertion is triggered due to the protocol database
is already locked. #8 calls #4 and the loop begins.
After changing #6 to CoreAcquireLockOrFail(), the assertion is
avoided and the loop is broken.
With the fix, NT32 can boot to Shell even setting
PcdDebugPrintErrorLevel to 0xFFFFFFFF, with all error levels turned
on.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ruiyu Ni <ruiyu.ni@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Current MemoryAttributesTable will be installed on ReadyToBoot event
at TPL_NOTIFY level, it maybe incorrect when PcdHiiOsRuntimeSupport
= TRUE as HiiDatabaseDxe will have runtime memory allocation for HII
OS runtime support on and after ReadyToBoot. The issue was exposed at
http://article.gmane.org/gmane.comp.bios.edk2.devel/10125.
To make sure the correctness of MemoryAttributesTable, this patch is
to enhance MemoryAttributesTable installation to install
MemoryAttributesTable on ReadyToBoot event at TPL_CALLBACK - 1 level
to make sure it is at the last of ReadyToBoot event, and also hook
runtime memory allocation after ReadyToBoot.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
The following patch for MemoryAttributesTable will need the memory type.
And CoreUpdateProfile() can also use the memory type for check.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Originally, the code block for "Report DXE Core image information to the PE/COFF
Extra Action Library" was after ProcessLibraryConstructorList(). To fix an issue,
ProcessLibraryConstructorList() was moved to be right after CoreInitializeGcdServices()
at c5d5379937, but the code block was left.
As there maybe PeCoffExtraActionLib implementation need Constructor executed first,
the patch is to move the code block for "Report DXE Core image information to the PE/COFF
Extra Action Library" to be after ProcessLibraryConstructorList.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Check for Type AllocateAddress,
if NumberOfPages is 0 or
if (NumberOfPages << EFI_PAGE_SHIFT) is above MAX_ADDRESS or
if (Start + NumberOfBytes) rolls over 0 or
if Start is above MAX_ADDRESS or
if End is above MAX_ADDRESS,
return EFI_NOT_FOUND.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Michael Kinney <michael.d.kinney@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
When the DXE core is loaded, it invokes the PeCoffExtraActionLib library
function 'PeCoffLoaderRelocateImageExtraAction' explicitly, which may be
in addition to the same function having been called by the DxeIpl PE/COFF
loader instance.
The ImageContext that DXE core presents to this function is only partially
initialized, which may result in the following output on AArch64 systems:
add-symbol-file ..MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0x5F226240
<some intermediate output>
add-symbol-file ..MdeModulePkg/Core/Dxe/DxeMain/DEBUG/DxeCore.dll 0x5F226000
This is caused by incorrect data in the ImageContext structure, which means
the start of the .text section is calculated incorrectly. In general, it is
the duty of the caller to present a valid ImageContext structure, so let's
add the missing values before invoking PeCoffLoaderRelocateImageExtraAction().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Star Zeng <star.zeng@intel.com>
When PcdShadowPeimOnBoot is FALSE, they are not copied to memory and
execute from their original locations. Here, this policy should only
apply for PEIM and PEI_CORE, not for other file type, such as DXE_CORE.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
Tested-by: Eugene Cohen <eugene@hp.com>
If 'CoreGetMemoryMap' return success the 'MemoryMap' shouldn't be NULL.
Add code to make sure this.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Qiu Shumin <shumin.qiu@intel.com>
Reviewed-by: Yao Jiewen <Jiewen.Yao@intel.com>
According to the spec, each entry in the Memory
Attributes table shall have the same type as
the region it was carved out of in the UEFI memory map.
The current attribute uses RTData for PE Data, but
it should be RTCode.
This patch fixed the issue. It is validated with or
without PropertiesTable.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Tested-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Liming Gao <liming.gao@intel.com>
MemoryAttributesTable generation need information in
PropertiesTable.
In memory attributes table generation path,
PropertiesTable need record original memory map and do
not merge the new memory map entry cross original
memory map boundary.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Gao, Liming" <liming.gao@intel.com>
Add MemoryAttributesTable generation in DxeCore.
We leverage the information collected by original
PropertiesTable, and publish runtime code/data to
another standalone table. So that this is a
compatible solution to report more PE Code/Data
information.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Gao, Liming" <liming.gao@intel.com>
At the end of CoreFreePoolI(), the check to see if it is a specific
memory type should also cover OEM reserved memory type.
It was missed when adding OEM reserved memory type support at R17460.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
If FV image without DXE depex, it will be dispatched by DxeCore.
If FV image with SMM depex, it is the invalid image. ASSERT will be trig.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Andrew Fish <afish@apple.com>
Reviewed-by: Michael Kinney <michael.d.kinney@intel.com>
(HandoffInformationTable->EfiFreeMemoryBottom - Private->HobList.Raw)
is the PEI temp heap used instead of the length of PEI temp heap.
The length of PEI temp heap should be:
(HandoffInformationTable->EfiFreeMemoryTop - Private->HobList.Raw)
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Cinnamon Shia <cinnamon.shia@hpe.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19762 6f19259b-4bc3-4df7-8a09-765794883524
Signal a closed event will still invoke the event notification function,
it could only be exposed when no the DEBUG_PROPERTY_CLEAR_MEMORY_ENABLED
bit set in PcdDebugPropertyMask.
For example:
gBS->CreateEvent (
EVT_NOTIFY_SIGNAL,
TPL_CALLBACK,
CallbackFun,
NULL,
&Event
);
gBS->CloseEvent (Event);
gBS->SignalEvent (Event); <- CallbackFun still be invoked
Although the case to signal a closed event is abnormal, the code could
still be enhanced to avoid it.
Cc: Liming Gao <liming.gao@intel.com>
Cc: Feng Tian <feng.tian@intel.com>
Cc: Thomas Palmer <thomas.palmer@hpe.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19754 6f19259b-4bc3-4df7-8a09-765794883524
The single line for(); construct is followed by code that is indented.
This triggers the -Wempty-body warning. Fix indentation.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Andrew Fish <afish@apple.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19420 6f19259b-4bc3-4df7-8a09-765794883524
In DxeCore, use warning message for Runtime driver that doesn't satisfy
section alignment requirement. This check is required when PropertiesTable
is installed. So, add error message if PropertiesTable can't be installed
successfully.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@19312 6f19259b-4bc3-4df7-8a09-765794883524
We had put communication buffer to Runtime memory,
so that SMI handler can know it is not used by OS.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18949 6f19259b-4bc3-4df7-8a09-765794883524
PiSmmCore installs LoadedImage for each SMM driver. However itself is missing.
So we follow DxeCore style, let PiSmmCore installs LoadedImage protocol for itself,
then the SMM image information is complete.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18945 6f19259b-4bc3-4df7-8a09-765794883524
Original code does not uninstall LoadedImage protocol if SMM driver returns error and is unloaded.
It causes a wrong LoadedImage protocol existing in system.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18936 6f19259b-4bc3-4df7-8a09-765794883524
Original code refers FreePoolHdr without check Status. It is obvious wrong and has risk.
Aslo, if InternalAllocPoolByIndex() returns an error, then *FreePoolHdr is assigned to an uninitialized value. So we init Hdr be NULL.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Zeng, Star" <star.zeng@intel.com>
Reviewed-by: "Yao, Jiewen" <jiewen.yao@intel.com>
Reviewed-by: "Fan, Jeff" <jeff.fan@intel.com>
Reviewed-by: "Kinney, Michael D" <michael.d.kinney@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18932 6f19259b-4bc3-4df7-8a09-765794883524
The ASSERT (PrivateData->PeiMemoryInstalled) in if (PrivateData->PeiMemoryInstalled)
condition is useless, it should be ASSERT (FALSE) to follow the code's expectation.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18887 6f19259b-4bc3-4df7-8a09-765794883524
A corner case like below will cause a NOT_DISPATCHED FV has no opportunity to
be dispatched.
1. FV_RECOVERY has SecCore, PeiCore and some other PEI modules, a module will
report FVMAIN_COMPACT and FV_RECOVERY2 in sequence.
2. FVMAIN_COMPACT has a FV image file with GUIDED FV image section in it.
3. FV_RECOVERY2 has DxeIpl and other PEI modules, the DxeIpl will install
SectionExtractionPpi
If ALL the PEIMs in FV_RECOVERY and FV_RECOVERY2 have DEPEX satisfied and
executed in one loop, PeimNeedingDispatch will be always FALSE, FVMAIN_COMPACT
will have no opportunity to be decompressed and dispatched as DxeIpl executes
after the first processing to FVMAIN_COMPACT.
The patch is to set PeimNeedingDispatch to TRUE when ProcessFvFile() not successfully,
then the NOT_DISPATCHED FV could have another opportunity to be processed.
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18781 6f19259b-4bc3-4df7-8a09-765794883524
This patch fixes an issue in PEI with encapsulated FV images where the
AuthenticationStatus is not correctly propagated down to child FV
handles. The PEI core registers for callbacks for both FvInfo and
FvInfo2 PPIs. These callbacks process the FVs which will recurse as
necessary to find more encapsulated FVs. (FvInfo2 is an updated PPI
that includes an AuthenticationStatus field - the original FvInfo did
not include this.)
When encapsulated FV processing occurs the PEI core installs both
FvInfo and FvInfo2 PPIs. The original implementation installs FvInfo
first and FvInfo2 second. As soon as the FvInfo PPI is installed the
notification callback handler immediately fires causing recursive FV
processing to occur. Since there is no AuthenticationStatus provided
for the original FvInfo the callback assumes AuthenticationStatus is
zero (unsigned / unverified) even though the parent FV may have been
verified.
This changes the order of FvInfo and FvInfo2 installs to ensure that
the notification callback occurs for FvInfo2 first and appropriate
AuthenticationStatus data can be propagated from parent FV to child
FV.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Eugene Cohen <eugene@hp.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18764 6f19259b-4bc3-4df7-8a09-765794883524
A subset of fields in the EFI_SMM_SYSTEM_TABLE2 structure are identical
to the fields in the SMM_ENTRY_CONTEXT structure. CopyMem() is used to
transfer the contents of the SMM_ENTRY_CONTEXT structure into the
EFI_SMM_SYSTEM_TABLE2. This is confusing because SMM_ENTRY_CONTEXT is
not used in the declaration of EFI_SMM_SYSTEM_TABLE2 and field contents
are transferred without any reference to individual field names (e.g.
CurrentlyExecutingCpu). In order to make the code easier to maintain
and understand, the CopyMem() is replaced with statements that transfer
each field of SMM_ENTRY_CONTEXT into EFI_SMM_SYSTEM_TABLE2.
Reported-by: Laszlo Ersek <lersek@redhat.com>
Link: http://article.gmane.org/gmane.comp.bios.edk2.devel/3567
Cc: Feng Tian <feng.tian@intel.com>
Cc: Jeff Fan <jeff.fan@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Michael Kinney <michael.d.kinney@intel.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18716 6f19259b-4bc3-4df7-8a09-765794883524
Mark the DXE stack region as non-executable right before handing
off to the DXE core, by invoking the appropriate ArmLib function.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Leif Lindholm <leif.lindholm@linaro.org>
Reviewed-by: Feng Tian <Feng.Tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18588 6f19259b-4bc3-4df7-8a09-765794883524
In a CloseEvent, an UnregisterProtocolNotify is done unconditionally.
There is a penalty associated with searching the protocol database on
every CloseEvent and impacts performance, especially during Network IO.
Unregister needs to be done only if the Event is for a RegisterProtocolNotify.
So extend the ExFlag in IEVENT to a UINT8 and define new flags that can
be set to indicate if the Event is part of a group, or registered on a
protocol notify. Then in CloseEvent, call UnregisterProtocolNotify only
if the register protocol notify flag is set.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Samer El-Haj-Mahmoud <samer.el-haj-mahmoud@hpe.com>
Reviewed-by: Feng Tian <feng.tian@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18517 6f19259b-4bc3-4df7-8a09-765794883524
Take the range in the resource descriptor HOB for the memory region described
by the PHIT as higher priority if it is big enough. It can make the memory bin
allocated to be at the same memory region with PHIT that has more better compatibility
to avoid memory fragmentation for some code practices assume and allocate <4G ACPI memory.
Also let the minimal memory size needed include the total memory bin size needed to
make sure memory bin could be allocated successfully.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18503 6f19259b-4bc3-4df7-8a09-765794883524
The HOB List relocation should be at after all the tested memory resources added
(except the memory space that covers HOB List) to the memory services,
because the memory resource found in CoreInitializeMemoryServices()
may have not enough remaining resource for HOB List.
And the memory space that covers HOB List should be processed
after HOB List relocation to avoid the resources allocated by others
to corrupt HOB List before its relocation.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18499 6f19259b-4bc3-4df7-8a09-765794883524
InternalIsBufferOverlapped() is created to check overlap between buffers.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18312 6f19259b-4bc3-4df7-8a09-765794883524
in case PeiInstallPeiMemory() is done in a callback with
EFI_PEI_PPI_DESCRIPTOR_NOTIFY_DISPATCH, and the callback is registered on
a PPI that is installed in the last PEIM.
At the case, PeiCore SwitchStack code will be not being invoked.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18305 6f19259b-4bc3-4df7-8a09-765794883524
Got the build failure feedback below, this patch is to fix that.
This broke the IA32 Ovmf build for me, with GCC 5.1.1 (Fedora 22):
/home/dwmw2/git/edk2/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c:377:7:
error: ‘PageTables’ may be used uninitialized in this function [-Werror=maybe-uninitialized]
AsmWriteCr3 (PageTables);
^
/home/dwmw2/git/edk2/MdeModulePkg/Core/DxeIplPeim/Ia32/DxeLoadFunc.c:224:9:
note: ‘PageTables’ was declared here
UINTN PageTables;
^
cc1: all warnings being treated as errors
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Qiu Shumin <shumin.qiu@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18190 6f19259b-4bc3-4df7-8a09-765794883524
This feature is added for UEFI spec that says
"Stack may be marked as non-executable in identity mapped page tables".
A PCD PcdSetNxForStack is added to turn on/off this feature, and it is
FALSE by default.
Cc: Jiewen Yao <jiewen.yao@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: "Yao, Jiewen" <Jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18166 6f19259b-4bc3-4df7-8a09-765794883524
to right after CoreInitializeGcdServices().
Why?
Some platforms maybe report both below 4G and above 4G memory resource hob as tested,
then CoreInitializeMemoryServices() will find and add the tested above 4G memory resource hob to memory descriptor for early memory allocation services,
then if ProcessLibraryConstructorList() that has library constructor tries to allocate below 4G memory and will fail.
In fact, the following CoreInitializeGcdServices() will add all the memory resource hob to GCD map,
and add the tested below 4G memory resource hob to memory descriptor,
but it has been too late for ProcessLibraryConstructorList().
Also move below two lines as they are needed to be after
the constructor of DxeCorePerfomanceLib.
PERF_END (NULL,"PEI", NULL, 0) ;
PERF_START (NULL,"DXE", NULL, 0) ;
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18146 6f19259b-4bc3-4df7-8a09-765794883524
v2 changelog:
Check CurrentPeimHandle to check the matched PeimHandle.
Add check point to ShadowPeiCore based on PCD.
v1 changelog:
PeiCore LoadImage always shadow itself and PEIM on normal boot after
the physical memory is installed. On the emulator platform, the shadow
may be not necessary. To support such usage, new PCD PcdShadowPeimOnBoot
is introduced to specify whether loads PEIM in memory by default.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18125 6f19259b-4bc3-4df7-8a09-765794883524
to instead of AllocatePool() to ensure the data is clean for
the following consumption.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18087 6f19259b-4bc3-4df7-8a09-765794883524
that assumes the SMRAM reserved range is only at the end of the SMRAM descriptor.
//
// This range has reserved area, calculate the left free size
//
gSmmCorePrivate->SmramRanges[Index].PhysicalSize = SmramResRegion->SmramReservedStart - gSmmCorePrivate->SmramRanges[Index].CpuStart;
Imagine the following scenario where we just reserve the first page of the SMRAM range:
SMRAM Descriptor:
Start: 0x80000000
Size: 0x02000000
Reserved Range:
Start: 0x80000000
Size: 0x00001000
In this case the adjustment to the SMRAM range size yields zero: ReservedStart - SMRAM Start is 0x80000000 - 0x80000000 = 0.
So even though most of the range is still free the IPL code decides its unusable.
The problem comes from the email thread: [edk2] PiSmmIpl SMRAM Reservation Logic.
http://thread.gmane.org/gmane.comp.bios.tianocore.devel/15268
Also to follow the idea in the email thread, the patch is to
1. Keep only one copy of full SMRAM ranges in gSmmCorePrivate->SmramRanges,
split record for SmmConfiguration->SmramReservedRegions and SMM Core that
will be marked to be EFI_ALLOCATED in gSmmCorePrivate->SmramRanges.
2. Handle SmmConfiguration->SmramReservedRegions at beginning of, at end of,
in the middle of, or cross multiple SmramRanges.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18031 6f19259b-4bc3-4df7-8a09-765794883524
Add the check at DxeLoadCore() on MdeModulePkg\Core\DxeIplPeim\DxeLoad.c
to skip install the "gEfiMemoryTypeInformationGuid" hob if it is already
installed.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@18018 6f19259b-4bc3-4df7-8a09-765794883524
GCD Range is byte address. EFI memory range is page address. To make sure
GCD range is converted to EFI memory range, the following things are added:
1. Merge adjacent GCD range first.
2. Add ASSERT check on GCD range alignment.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17813 6f19259b-4bc3-4df7-8a09-765794883524
The splitting of memory regions into code and data regions violates
architecture specific alignment rules by using a fixed alignment
of 4 KB. Replace it with EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT,
which is defined appropriately on each architecture.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Jaben Carsey" <jaben.carsey@intel.com>
Reviewed-by: "Yao, Jiewen" <Jiewen.Yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17812 6f19259b-4bc3-4df7-8a09-765794883524
Move the definitions of EFI_ACPI_RUNTIME_PAGE_ALLOCATION_ALIGNMENT and
DEFAULT_PAGE_ALLOCATION to DxeMain.h to make them available explicitly
to all parts of DxeCore.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <Jiewen.Yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17811 6f19259b-4bc3-4df7-8a09-765794883524
This removes the functions RevertRuntimeMemoryMap () and
DumpMemoryMap () which are not referenced anywhere in the code.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: "Yao, Jiewen" <Jiewen.Yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17808 6f19259b-4bc3-4df7-8a09-765794883524
UEFI Spec HTTP Boot Device Path, after retrieving the boot resource
information, the BootURI device path node will be updated to include
the BootURI information. It means the device path on the child handle
will be updated after the LoadFile() service is called.
To handle this case, DxeCore LoadImage() service is updated as the below:
1) Get Device handle based on Device Path
2) Call LoadFile() service (GetFileBufferByFilePath() API) to get Load File Buffer.
3) Retrieve DevicePath from Device handle
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17799 6f19259b-4bc3-4df7-8a09-765794883524
Child FV may be placed in parent FV image without process required. Then,
Child FV and parent FV will be in the same continuous space. For FileHandle,
FileHandleToVolume() function needs to find the best matched FV handle.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17704 6f19259b-4bc3-4df7-8a09-765794883524
UEFI2.5 spec, GetMemoryMap(), says:
Attribute: Attributes of the memory region that describe the bit mask
of capabilities for that memory region, and not necessarily the current
settings for that memory region.
But, GetMemoryMap() implementation doesn't append memory capabilities
for MMIO and Reserved memory range. This will break UEFI2.5 Properties
Table feature, because Properties Table need return EFI_MEMORY_RO or
EFI_MEMORY_XP capabilities for OS.
This patch appends memory capabilities for those memory range.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17703 6f19259b-4bc3-4df7-8a09-765794883524
And also SMM Ready To Boot.
The SMM Exit Boot Service protocol is to be published by the SMM
Foundation code to associate with EFI_EVENT_GROUP_EXIT_BOOT_SERVICES
to notify SMM driver that system enter exit boot services.
The SMM Legacy Boot protocol is to be published by the SMM
Foundation code to associate with EFI_EVENT_LEGACY_BOOT_GUID
to notify SMM driver that system enter legacy boot.
The SMM Ready To Boot protocol is to be published by the SMM
Foundation code to associate with EFI_EVENT_GROUP_READY_TO_BOOT
to notify SMM driver that system enter ready to boot.
After them, any SMM drivers can get protocol notify on what happened
in DXE phase, then there is no need to let each individual SMM driver
to register SMM Communication Handler for that.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17657 6f19259b-4bc3-4df7-8a09-765794883524
The correct logic should be:
- The SectionAlignment is got from Magic number.
- The Magic number is got from PE header and machine type.
The original code mix them.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: "Yao, Jiewen" <Jiewen.yao@intel.com>
Reviewed-by: "Ard Biesheuvel" <ard.biesheuvel@linaro.org>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17603 6f19259b-4bc3-4df7-8a09-765794883524
1. In PiSmmIpl.c, free FullSmramRanges at error condition.
2. Move pool and page management definitions and structures
from PiSmmCorePrivateData.h to PiSmmCore.h.
PiSmmCorePrivateData.h should be only used to share SMM_CORE_PRIVATE_DATA
between PiSmmCore and PiSmmIpl. Pool and page management definitions
and structures were moved from Pool.c and Page.c to PiSmmCorePrivateData.h
incorrectly for memory profile feature at EDK2 R16335 commit.
3. DumpSmramInfo() only used for memory profile, so move the declaration
into SmramProfileRecord.c.
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17598 6f19259b-4bc3-4df7-8a09-765794883524
Use if (Image->Started) condition judgement before call to
UnregisterMemoryProfileImage() in CoreUnloadAndCloseImage().
Contributed-under: TianoCore Contribution Agreement 1.0
Signed-off-by: Star Zeng <star.zeng@intel.com>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
git-svn-id: https://svn.code.sf.net/p/edk2/code/trunk/edk2@17597 6f19259b-4bc3-4df7-8a09-765794883524
Star Zeng
Jian J Wang
Laszlo Ersek
Liming Gao
Michael D Kinney
Dandan Bi
Eric Dong
Hao Wu
Amit Kumar
Ruiyu Ni
Shi, Steven
Jiewen Yao
Ard Biesheuvel
Fu Siyuan
Leo Duran
Jeff Fan
Gary Lin
Marvin Haeuser
Giri P Mudusuru
Jordan Justen
Cohen, Eugene
Zhang, Chao B
Qiu Shumin
Cinnamon Shia
Andrew Fish
Samer El-Haj-Mahmoud