| Age | Commit message (Collapse) | Author | Files | Lines |
|---|
|
https://github.com/github/codeql/blob/codeql-cli-2.7.3/cpp/ql/src/Critical/MissingNullTest.qhelp
For items which allocate memory, or get a pointer from another
structure, it is important to validate that the pointers
are not null before they are dereferenced.
Signed-off-by: Aaron Pop <aaronpop@microsoft.com>
|
|
Memory Attributes Table needs to be updated to contain executable
permissions for UEFI runtime drivers loaded after EndOfDxe.
Fixes a regression introduced by bb248a9.
Signed-off-by: Vitaly Cheptsov <vit9696@protonmail.com>
|
|
edk2 commit 3bd5c994c879f78e8e3d5346dc3b627f199291aa added usage
of EFI_MEMORY_ATTRIBUTE_MASK to edk2. However, it applied it
incorrectly to some places that should instead use
EFI_MEMORY_ACCESS_MASK. EFI_MEMORY_ACCESS_MASK contains the actual
HW page table access attributes (read protect, read only, no-execute),
whereas EFI_MEMORY_ATTRIBUTE_MASK contains the access attributes in
addition to some virtual attributes (special purpose and cpu crypto).
The GCD has a behavior where if SetMemorySpaceAttributes() is called
with only virtual attributes set, it will not call into CpuDxe to
change the attributes; 0 is a valid page table attribute set (it means
RWX). However, after the above change, this behavior was altered so
that if EFI_MEMORY_SP or EFI_MEMORY_CPU_CRYPTO is applied, in attempt
to just update these virtual attributes, the GCD will call into CpuDxe
and apply RWX instead, which is not the intention of the caller.
One other place this was done incorrectly was in CoreGetMemoryMap,
but that was fixed in f1567720b13a578ffa54716119f826df622babcd.
SetUefiImageMemoryAttributes() is also updated here because that
logic was copied from the check the GCD has about whether to call
CpuDxe or not. Now that the GCD has been corrected, this also
needs to be corrected.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
Currently, if the DebugClearMemory bit is set in the
PcdDebugPropertyMask, CoreConvertPagesEx will attempt to write
a pattern to the pages being freed. However, it does not check
that the page is writeable, which will cause a page fault if not.
Furthermore, if NX protections are not enabled, the core does not
ensure that any freed pages are RW, which is the state expected
when they are allocated next. If they are not RW, the allocating
driver will crash trying to use them.
This patch updates the page freeing code to query the memory
attributes protocol, if present, for the attributes. If this call
fails or the attributes are not RW at a minimum, the core leaks
the memory (returning success to the caller). If the memory
attribute protocol is not present (either because a platform doesn't
produce it or it is before the protocol has been produced, the core
continues with freeing memory. This is either before the CPU Arch
protocol is available (so drivers can't change memory attributes) or
otherwise matches existing behavior. This was deemed the best
approach to let memory that can't be guaranteed to be RW leak
instead of letting a driver crash when allocating it. It was deemed
less brittle to simply leak the memory instead of attempting to
change the attributes.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
The DebugImageInfoTable contains an array of image info
structures. The current implementation removes an entry by
freeing the info structure and putting NULL in that entry of
the array. It then decrements the table size tracked in the table.
However, the array is invalid at this point, it contains a NULL
entry, which the UEFI spec does not envision and it contains a valid
entry past the end of the array as tracked in the spec defined config
table. If the table is consumed at this point it can lead to an
invalid assessment of the image state, which defeats the purpose of
the table.
When a new info structure is added, it then scans for the first NULL
entry adds a pointer to the new info structure there and increments
the table size to cover the entrythat was formerly past the end of
the array.
The current implementation requires that once an unload happens,
more loads happen than unloads and that the last operation is not
an unload (which won't be true in the shell, e.g.). This is
needlessly complex, as the order of the table doesn't matter
(and in fact this implementation doesn't preserve image loading
order either).
This patch updates the removal function to free the desired
info structure, move the last entry of the array to this freed
spot, mark the last entry as NULL, and decrement the table count.
The entry addition function then just always puts a new entry at
the end of the array, expanding it as necessary. This simplifies
the logic and covers the gaps that were present.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
Commit 5ccb5fff02a66b21898bd57f48bbd7c3cd6f4e8d updated the
image memory protection code to set the protection
attributes through the GCD instead of directly to the page
table. However, this code had an implicit assumption that
each base address passed to it was the beginning of a GCD
descriptor. On the virtual platforms tested, this was the case.
However, on a physical platform, a scenario was encountered
where the base address was not the beginning of a GCD
descriptor, thus causing memory attributes to be applied
incorrectly.
This assumption does not need to be made and this patch
updates the code to handle the case where the base address
is not the beginning of a GCD descriptor.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
Today, SetUefiImageMemoryAttributes calls directly to the
CPU Arch protocol to set EFI_MEMORY_XP or EFI_MEMORY_RO on
image memory. However, this bypasses the GCD and so the GCD
is out of sync with the actual state of memory.
This can cause an issue in the scenario where a new attribute
is being set (whether a virtual attribute or a real HW attribute),
if the GCD attributes are queried for a region and the new attribute
is appended to the existing GCD attributes (which are incorrect),
then the incorrect attributes can get applied. This can result in
setting EFI_MEMORY_XP on code sections of images and causing an
execution fault.
This patch updates SetUefiImageMemoryAttributes to call into the
GCD to update the attributes there and let the GCD code call into
the CPU Arch protocol to update the page table.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
The print that describes memory attributes being applied to image
memory sections is currently at info level and very noisy, being
printed multiple times per image.
Reduce this to the verbose logging level.
Signed-off-by: Oliver Smith-Denny <osde@microsoft.com>
|
|
Check that the next map entry is valid before dereferencing to merge the
guard pages. If the final entry is at the end of a page with no valid page
following it, then this can cause an access violation.
Signed-off-by: Kenneth Lautner <kenlautner3@gmail.com>
|
|
The Memory Attributes Table is generated by fetching the EFI memory map
and splitting entries which contain loaded images so DATA and CODE
sections have separate descriptors. The splitting is done via a call to
SplitTable() which
marks image DATA sections with the EFI_MEMORY_XP attribute and CODE
sections with the EFI_MEMORY_RO attribute when
splitting. After this process, there may still be EfiRuntimeServicesCode
regions which did not have their attributes set because they are not
part of loaded images.
This patch updates the MAT EnforceMemoryMapAttribute logic to set the
access attributes of runtime memory regions which are not part of loaded
images (have not had their access attributes set). The attributes of the
code regions will be read-only and no-execute because the UEFI spec
dictates that runtime code regions should only contain loaded EFI
modules.
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4832
Refs:
1.
https://edk2.groups.io/g/devel/topic/patch_v1_mdemodulepkg/105570114?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105570114
2.
https://edk2.groups.io/g/devel/topic/mdemodulepkg_fix_mat/105477564?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105477564
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
|
|
Per UEFI spec 2.10 section 4.6.3 EFI_MEMORY_ATTRIBUTES_TABLE,
"The Memory Attributes Table is currently used to describe memory
protections that may be applied to the EFI Runtime code and data
by an operating system or hypervisor. Consumers of this table must
currently ignore entries containing any values for Type except for
EfiRuntimeServicesData and EfiRuntimeServicesCode to ensure
compatibility with future uses of this table."
However, the current MAT code also enforces attributes for
EfiMemoryMappedIo and EfiMemoryMappedIoPortSpace, which it should
not be. Per
https://edk2.groups.io/g/devel/topic/patch_v1_mdemodulepkg/105570114?p=,,,20,0,0,0::recentpostdate/sticky,,,20,2,0,105570114,
it was suggested to remove these types from the MAT logic.
This patch removes EfiMemoryMappedIo and EfiMemoryMappedIoPortSpace
from the MAT logic in accordance with the UEFI spec.
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
|
|
The functionality to create and delete Image Records has been
consolidated in a library and ensured that MemoryProtection.c's
usage is encapsulated there.
This patch moves MemoryProtection.c to reuse the code in the lib
and to prevent issues in the future where code is updated in one
place but not the other.
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Taylor Beebe <taylor.d.beebe@gmail.com>
Acked-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
|
|
Per the UEFI spec 2.10, section 2.3.6 (for the AARCH64 arch, other
architectures in section two confirm the same) the memory types that
need runtime page allocation granularity are EfiReservedMemoryType,
EfiACPIMemoryNVS, EfiRuntimeServicesCode, and EfiRuntimeServicesData.
However, legacy code was setting runtime page allocation granularity for
EfiACPIReclaimMemory and not EfiReservedMemoryType. This patch fixes
that error.
Cc: Leif Lindholm <quic_llindhol@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianocore@kernel.org>
Cc: Sami Mujawar <sami.mujawar@arm.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Signed-off-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Suggested-by: Ard Biesheuvel <ardb+tianocore@kernel.org>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
Update DumpImageRecord() to be DumpImageRecords(), and improve
the debug output. The function will output at DEBUG_INFO instead,
and the function will be run in DXE and SMM
MAT logic when the MAT is installed at EndOfDxe on DEBUG builds.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
Add logic to create and delete image properties records. Where
applicable, redirect existing code to use the new library.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Jiaxin Wu <jiaxin.wu@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
|4K PAGE|DATA|CODE|DATA|CODE|DATA|4K PAGE|
Say the above memory region is currently one memory map descriptor.
The above image memory layout example contains two code sections
oriented in a way that maximizes the number of descriptors which
would be required to describe each section.
NOTE: It's unlikely that a data section would ever be between
two code sections, but it's still handled by the below formula
for correctness.
There are two code sections (let's say CodeSegmentMax == 2),
three data sections, and two unrelated memory regions flanking the
image. The number of required descriptors to describe this layout
will be 2 * 2 + 3 == 7. This patch updates the calculations to account
for the worst-case scenario.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
Move some DXE MAT logic to ImagePropertiesRecordLib to consolidate
code and enable unit testability.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
This patch updates MemoryAttributesTable.c to reduce reliance on global
variables and allow some logic to move to a library.
Cc: Jian J Wang <jian.j.wang@intel.com>
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Cc: Dandan Bi <dandan.bi@intel.com>
Signed-off-by: Taylor Beebe <taylor.d.beebe@gmail.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
__FUNCTION__ is a pre-standard extension that gcc and Visual C++ among
others support, while __func__ was standardized in C99.
Since it's more standard, replace __FUNCTION__ with __func__ throughout
MdeModulePkg.
Signed-off-by: Rebecca Cran <rebecca@bsdio.com>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Ard Biesheuvel <ardb@kernel.org>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=4405
The memory attributes table has been extended with a flag that indicates
whether or not the OS is permitted to map the EFI runtime code regions
with strict enforcement for IBT/BTI landing pad instructions.
Given that the PE/COFF spec now defines a DllCharacteristicsEx flag that
indicates whether or not a loaded image is compatible with this, we can
wire this up to the flag in the memory attributes table, and set it if
all loaded runtime image are compatible with it.
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osde@linux.microsoft.com>
Reviewed-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
UEFI v2.10 introduces a new flag to the memory attributes table to
inform the OS whether or not runtime services code regions were emitted
by the compiler with guard instructions for forward edge control flow
integrity enforcement.
So update our definition accordingly.
Link: https://uefi.org/specs/UEFI/2.10/04_EFI_System_Table.html#efi-memory-attributes-table
Signed-off-by: Ard Biesheuvel <ardb@kernel.org>
Reviewed-by: Michael D Kinney <michael.d.kinney@intel.com>
Acked-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Leif Lindholm <quic_llindhol@quicinc.com>
Reviewed-by: Oliver Smith-Denny <osd@smith-denny.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3737
Apply uncrustify changes to .c/.h files in the MdeModulePkg package
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Signed-off-by: Michael Kubacki <michael.kubacki@microsoft.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=3739
Update all use of EFI_D_* defines in DEBUG() macros to DEBUG_* defines.
Cc: Andrew Fish <afish@apple.com>
Cc: Leif Lindholm <leif@nuviainc.com>
Cc: Michael Kubacki <michael.kubacki@microsoft.com>
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Liming Gao <gaoliming@byosoft.com.cn>
|
|
Add usage of EFI_MEMORY_SP and EFI_MEMORY_CPU_CRYPTO
attributes introduced in UEFI 2.8
(UEFI 2.8, mantis 1919 and 1872)
Use attributes bitmasks, defined in MdePkg.
Signed-off-by: Oleksiy Yakovlev <oleksiyy@ami.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Message-Id: <20200702205039.52400-3-oleksiyy@ami.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Tested-by: Laszlo Ersek <lersek@redhat.com>
|
|
The memory attributes table handling code shared some parts of the
properties table handling code when it was introduced. The latter has
been dropped, and so we can merge the remaining pieces into the former.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Reviewed-by: Bret Barkelew <bret.barkelew@microsoft.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
|
|
This is the minimal change required to stop exposing the EFI properties
table, which is deprecated. Given how the implementation is entangled
with the code that exposes the related memory attributes table, most of
the code is retained, and further cleanups are relegated to subsequent
patches.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=2633
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@arm.com>
Acked-by: Jiewen Yao <Jiewen.yao@intel.com>
Acked-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Dandan Bi <dandan.bi@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
|
|
To solve access issue reported by BZ1885, page 0 will be allocated to
avoid misuses if NULL pointer detection is enabled. It should be better
to be freed after EndOfDxe if BIT7 of PcdNullPointerDetectionPropertyMask
is set, because NULL pointer detection is no longer available after
EndOfDxe and there will be no access conflict.
Ref: https://bugzilla.tianocore.org/show_bug.cgi?id=1885
Cc: Dandan Bi <dandan.bi@intel.com>
Cc: Liming Gao <liming.gao@intel.com>
Cc: Ray Ni <ray.ni@intel.com>
Cc: Hao A Wu <hao.a.wu@intel.com>
Cc: Sean Brogan <sean.brogan@microsoft.com>
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ray Ni <ray.ni@intel.com>
|
|
https://bugzilla.tianocore.org/show_bug.cgi?id=1373
Replace BSD 2-Clause License with BSD+Patent License. This change is
based on the following emails:
https://lists.01.org/pipermail/edk2-devel/2019-February/036260.html
https://lists.01.org/pipermail/edk2-devel/2018-October/030385.html
RFCs with detailed process for the license change:
V3: https://lists.01.org/pipermail/edk2-devel/2019-March/038116.html
V2: https://lists.01.org/pipermail/edk2-devel/2019-March/037669.html
V1: https://lists.01.org/pipermail/edk2-devel/2019-March/037500.html
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Michael D Kinney <michael.d.kinney@intel.com>
Reviewed-by: Hao Wu <hao.a.wu@intel.com>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
|
|
REF: https://bugzilla.tianocore.org/show_bug.cgi?id=1295
This issue originates from following patch which allows to enable
paging if PcdImageProtectionPolicy and PcdDxeNxMemoryProtectionPolicy
(in addition to PcdSetNxForStack) are set to enable related features.
5267926134d17e86672b84fd57b438f05ffa68e1
Due to above change, PcdImageProtectionPolicy will be set to 0 by
default in many platforms, which, in turn, cause following code in
MdeModulePkg\Core\Dxe\Misc\MemoryProtection.c fail the creation of
notify event of CpuArchProtocol.
1138: if (mImageProtectionPolicy != 0 ||
PcdGet64 (PcdDxeNxMemoryProtectionPolicy) != 0) {
1139: Status = CoreCreateEvent (
...
1142: MemoryProtectionCpuArchProtocolNotify,
...
1145: );
Then following call flow won't be done and Guard pages will not be
set as not-present in SetAllGuardPages() eventually.
MemoryProtectionCpuArchProtocolNotify()
=> HeapGuardCpuArchProtocolNotify()
=> SetAllGuardPages()
The solution is removing the if(...) statement so that the notify
event will always be created and registered. This won't cause
unnecessary code execution because, in the notify event handler,
the related PCDs like
PcdImageProtectionPolicy and
PcdDxeNxMemoryProtectionPolicy
will be checked again before doing related jobs.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
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>
|
|
At the end of of MemoryProtectionCpuArchProtocolNotify there's cleanup
code to free resource. But at line 978, 994, 1005 the function returns
directly. This patch use "goto" to replace "return" to make sure the
resource is freed before exit.
1029: CoreCloseEvent (Event);
1030: return;
There's another memory leak after calling gBS->LocateHandleBuffer() in
the same function:
Status = gBS->LocateHandleBuffer (
ByProtocol,
&gEfiLoadedImageProtocolGuid,
NULL,
&NoHandles,
&HandleBuffer
);
HandleBuffer is allocated in above call but never freed. This patch
will also add code to free it.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Cc: Leif Lindholm <leif.lindholm@linaro.org>
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>
|
|
Freed-memory guard is used to detect UAF (Use-After-Free) memory issue
which is illegal access to memory which has been freed. The principle
behind is similar to pool guard feature, that is we'll turn all pool
memory allocation to page allocation and mark them to be not-present
once they are freed.
This also implies that, once a page is allocated and freed, it cannot
be re-allocated. This will bring another issue, which is that there's
risk that memory space will be used out. To address it, the memory
service add logic to put part (at most 64 pages a time) of freed pages
back into page pool, so that the memory service can still have memory
to allocate, when all memory space have been allocated once. This is
called memory promotion. The promoted pages are always from the eldest
pages which haven been freed.
This feature brings another problem is that memory map descriptors will
be increased enormously (200+ -> 2000+). One of change in this patch
is to update MergeMemoryMap() in file PropertiesTable.c to allow merge
freed pages back into the memory map. Now the number can stay at around
510.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Michael D Kinney <michael.d.kinney@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@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>
|
|
Now that Itanium support has been dropped, we can remove the various
occurrences of the ELILO on Itanium PE/COFF header workaround.
Link: https://bugzilla.tianocore.org/show_bug.cgi?id=816
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Ard Biesheuvel <ard.biesheuvel@linaro.org>
Reviewed-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Laszlo Ersek <lersek@redhat.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
|
|
Some redundant library classes and GUIDs
have been removed in inf, .c and .h files.
https://bugzilla.tianocore.org/show_bug.cgi?id=1044
https://bugzilla.tianocore.org/show_bug.cgi?id=1045
https://bugzilla.tianocore.org/show_bug.cgi?id=1047
https://bugzilla.tianocore.org/show_bug.cgi?id=1049
https://bugzilla.tianocore.org/show_bug.cgi?id=1051
https://bugzilla.tianocore.org/show_bug.cgi?id=1052
https://bugzilla.tianocore.org/show_bug.cgi?id=1053
https://bugzilla.tianocore.org/show_bug.cgi?id=1054
https://bugzilla.tianocore.org/show_bug.cgi?id=1055
https://bugzilla.tianocore.org/show_bug.cgi?id=1056
https://bugzilla.tianocore.org/show_bug.cgi?id=1017
https://bugzilla.tianocore.org/show_bug.cgi?id=1035
https://bugzilla.tianocore.org/show_bug.cgi?id=1033
https://bugzilla.tianocore.org/show_bug.cgi?id=1012
https://bugzilla.tianocore.org/show_bug.cgi?id=1011
https://bugzilla.tianocore.org/show_bug.cgi?id=1062
v2:
1. Correct copyright year.
2. Fix alignment issue in AcpiPlatformDxe.inf.
3. Add DevicePathLib which is removed before in I2cHostDxe.inf.
4. Update NvmExpressPei.inf, NvmExpressPei.h, IScsiDxe.inf,
IScsiDxe.inf, IScsiDxe.h, DxeMain.inf, DxeMain.h, PiSmmCore.inf
and PiSmmCore.h for https://bugzilla.tianocore.org/show_bug.cgi?id=1062.
v3:
1. Add https://bugzilla.tianocore.org/show_bug.cgi?id=1062 to the
link list.
2. Remove DevicePathLib from I2cHostDxe.inf.
3. Update NvmExpressPei.inf, NvmExpressPei.h, UfsPciHcDxe.inf,
UfsPciHcDxe.h, I2cHostDxe.inf, AtaBusDxe.inf, IScsiDxe.inf,
IScsiDxe.h, DxeMain.inf, DxeMain.h, PiSmmCore.inf and PiSmmCore.h
for https://bugzilla.tianocore.org/show_bug.cgi?id=1062.
(Forget to add UfsPciHcDxe.inf, UfsPciHcDxe.h, AtaBusDxe.inf,
and I2cHostDxe.inf previously.)
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: shenglei <shenglei.zhang@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
|
|
We want to provide precise info in MemAttribTable
to both OS and SMM, and SMM only gets the info at EndOfDxe.
So we do not update RtCode entry in EndOfDxe.
The impact is that if 3rd part OPROM is runtime, it cannot be executed
at UEFI runtime phase.
Currently, we do not see compatibility issue, because the only runtime
OPROM we found before in UNDI, and UEFI OS will not use UNDI interface
in OS.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
|
|
So that the SMM can consume it to set page protection for
the UEFI runtime page with EFI_MEMORY_RO attribute.
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jiewen Yao <jiewen.yao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
|
|
1. Do not use tab characters
2. No trailing white space in one line
3. All files must end with CRLF
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Liming Gao <liming.gao@intel.com>
Reviewed-by: Star Zeng <star.zeng@intel.com>
|
|
Due to the fact that HeapGuard needs CpuArchProtocol to update page
attributes, the feature is normally enabled after CpuArchProtocol is
installed. Since there're some drivers are loaded before CpuArchProtocl,
they cannot make use HeapGuard feature to detect potential issues.
This patch fixes above situation by updating the DXE core to skip the
NULL check against global gCpu in the IsMemoryTypeToGuard(), and adding
NULL check against gCpu in SetGuardPage() and UnsetGuardPage() to make
sure that they can be called but do nothing. This will allow HeapGuard to
record all guarded memory without setting the related Guard pages to not-
present.
Once the CpuArchProtocol is installed, a protocol notify will be called
to complete the work of setting Guard pages to not-present.
Please note that above changes will cause a #PF in GCD code during cleanup
of map entries, which is initiated by CpuDxe driver to update real mtrr
and paging attributes back to GCD. During that time, CpuDxe doesn't allow
GCD to update memory attributes and then any Guard page cannot be unset.
As a result, this will prevent Guarded memory from freeing during memory
map cleanup.
The solution is to avoid allocating guarded memory as memory map entries
in GCD code. It's done by setting global mOnGuarding to TRUE before memory
allocation and setting it back to FALSE afterwards in GCD function
CoreAllocateGcdMapEntry().
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: 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: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
If enabled, NX memory protection feature will mark some types of active
memory as NX (non-executable), which includes the first page of the stack.
This will overwrite the attributes of the first page of the stack if the
stack guard feature is also enabled.
The solution is to override the attributes setting to the first page of
the stack by adding back the 'EFI_MEMORY_RP' attribute when the stack
guard feature is enabled.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@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>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
The commit rewrites the logic in function
InitializeDxeNxMemoryProtectionPolicy() for handling the first page
(page 0) when NULL pointer detection feature is enabled.
Instead of skip setting the page 0, the codes will now override the
attribute setting of page 0 by adding the 'EFI_MEMORY_RP' attribute.
The purpose is to make it easy for other special handling of pages
(e.g. the first page of the stack when stack guard feature is enabled).
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@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>
Reviewed-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
Considering following scenario (both NX memory protection and heap guard
are enabled):
1. Allocate 3 pages. The attributes of adjacent memory pages will be
|NOT-PRESENT| present | present | present |NOT-PRESENT|
2. Free the middle page. The attributes of adjacent memory pages should be
|NOT-PRESENT| present |NOT-PRESENT| present |NOT-PRESENT|
But the NX feature will overwrite the attributes of middle page. So it
looks still like below, which is wrong.
|NOT-PRESENT| present | PRESENT | present |NOT-PRESENT|
The solution is checking the first and/or last page of a memory block to be
marked as NX, and skipping them if they are Guard pages.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
If enabled, NX memory protection feature will mark all free memory as
NX (non-executable), including page 0. This will overwrite the attributes
of page 0 if NULL pointer detection feature is also enabled and then
compromise the functionality of it. The solution is skipping the NX
attributes setting to page 0 if NULL pointer detection feature is enabled.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: Jiewen Yao <jiewen.yao@intel.com>
Cc: Ruiyu Ni <ruiyu.ni@intel.com>
Contributed-under: TianoCore Contribution Agreement 1.1
Signed-off-by: Jian J Wang <jian.j.wang@intel.com>
Reviewed-by: Ruiyu Ni <ruiyu.ni@intel.com>
|
|
Three issues addressed here:
a. Make NX memory protection and heap guard to be compatible
The solution is to check PcdDxeNxMemoryProtectionPolicy in Heap Guard to
see if the free memory should be set to NX, and set the Guard page to NX
before it's freed back to memory pool. This can solve the issue which NX
setting would be overwritten by Heap Guard feature in certain
configuration.
b. Returned pool address was not 8-byte aligned sometimes
This happened only when BIT7 is not set in PcdHeapGuardPropertyMask. Since
8-byte alignment is UEFI spec required, letting allocated pool adjacent to
tail guard page cannot be guaranteed.
c. NULL address handling due to allocation failure
When allocation failure, normally a NULL will be returned. But Heap Guard
code will still try to adjust the starting address of it, which will cause
a non-NULL pointer returned.
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: 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>
|
|
The root cause is that mImagePropertiesPrivateData.CodeSegmentCountMax was
not updated with correct value due to the fact that SortImageRecord() called
before might change the content of current ImageRecord. This will in turn
cause incorrect memory map entries generated in SplitTable().
Cc: Star Zeng <star.zeng@intel.com>
Cc: Eric Dong <eric.dong@intel.com>
Cc: 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>
|
|
In commit 7eb927db3e25 ("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>
|
|
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>
|
|
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: Hao Wu <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
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>
|
|
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>
|
|
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>
|
|
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>
|
