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
Star Zeng
Amit Kumar
Shi, Steven
Liming Gao
Hao Wu
Jiewen Yao
Ard Biesheuvel
Dandan Bi
Laszlo Ersek
Fu Siyuan
Leo Duran
Michael Kinney
Jeff Fan
Gary Lin
Marvin Haeuser
Giri P Mudusuru
Jordan Justen
Cohen, Eugene
Zhang, Chao B
Ruiyu Ni
Qiu Shumin
Cinnamon Shia
Andrew Fish
Samer El-Haj-Mahmoud