Branch: refs/heads/master
  Home:   https://github.com/tianocore/edk2
  Commit: 019feb42a1dd1136014b19df3fcb618861b621e3
      
https://github.com/tianocore/edk2/commit/019feb42a1dd1136014b19df3fcb618861b621e3
  Author: Oliver Smith-Denny <o...@linux.microsoft.com>
  Date:   2024-03-14 (Thu, 14 Mar 2024)

  Changed paths:
    M MdeModulePkg/MdeModulePkg.ci.yaml
    M MdeModulePkg/MdeModulePkg.dsc

  Log Message:
  -----------
  MdeModulePkg: Remove ArmPkg Dependency

With commita21a994f55e53325d3e060c435ca3a87fd7c2c79 MdeModulePkg no
longer has a hard dependency on ArmMmuLib and therefore ArmLib. This is
the final dependency on ArmPkg, so remove the unused libs and drop the
allowed dependency on ArmPkg as MdeModulePkg should not depend on it as
this is a circular dependency.

Github PR: https://github.com/tianocore/edk2/pull/5361
BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=3651

Cc: Leif Lindholm <quic_llind...@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org>
Cc: Sami Mujawar <sami.muja...@arm.com>
Cc: Liming Gao <gaolim...@byosoft.com.cn>

Signed-off-by: Oliver Smith-Denny <o...@linux.microsoft.com>
Reviewed-by: Sean Brogan <sean.bro...@microsoft.com>
Acked-by: Ard Biesheuvel <a...@kernel.org>
Reviewed-by: Liming Gao <gaolim...@byosoft.com.cn>


  Commit: bf8f16f771d48c7cb4c0dfa548d296972513efe2
      
https://github.com/tianocore/edk2/commit/bf8f16f771d48c7cb4c0dfa548d296972513efe2
  Author: Oliver Smith-Denny <o...@linux.microsoft.com>
  Date:   2024-03-14 (Thu, 14 Mar 2024)

  Changed paths:
    M MdeModulePkg/Core/Dxe/Mem/Page.c

  Log Message:
  -----------
  MdeModulePkg: DxeCore: Fix CodeQL Error in FreePages

CodeQL flags the Free Pages logic for not ensuring that
Entry is non-null before using it. Add a check for this
and appropriately bail out if we hit this case.

Cc: Liming Gao <gaolim...@byosoft.com.cn>
Signed-off-by: Oliver Smith-Denny <o...@linux.microsoft.com>
Reviewed-by: Liming Gao <gaolim...@byosoft.com.cn>


  Commit: 68461c2c37afe11c7dda2769efc10bf20d2a7b23
      
https://github.com/tianocore/edk2/commit/68461c2c37afe11c7dda2769efc10bf20d2a7b23
  Author: Oliver Smith-Denny <o...@linux.microsoft.com>
  Date:   2024-03-14 (Thu, 14 Mar 2024)

  Changed paths:
    M MdeModulePkg/Core/Dxe/Mem/Page.c
    M MdeModulePkg/Core/Dxe/Mem/Pool.c
    M MdeModulePkg/Core/Dxe/Misc/MemoryProtection.c
    M MdeModulePkg/Core/Pei/Memory/MemoryServices.c

  Log Message:
  -----------
  MdeModulePkg: DxeCore: Correct Runtime Granularity Memory Type

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_llind...@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org>
Cc: Sami Mujawar <sami.muja...@arm.com>
Cc: Liming Gao <gaolim...@byosoft.com.cn>

Signed-off-by: Oliver Smith-Denny <o...@linux.microsoft.com>
Suggested-by: Ard Biesheuvel <ardb+tianoc...@kernel.org>
Reviewed-by: Liming Gao <gaolim...@byosoft.com.cn>


  Commit: e7486b50646d6a645706b61d2f8d74b3dca23ce0
      
https://github.com/tianocore/edk2/commit/e7486b50646d6a645706b61d2f8d74b3dca23ce0
  Author: Oliver Smith-Denny <o...@linux.microsoft.com>
  Date:   2024-03-14 (Thu, 14 Mar 2024)

  Changed paths:
    M MdeModulePkg/Core/Dxe/Mem/HeapGuard.h
    M MdeModulePkg/Core/Dxe/Mem/Page.c
    M MdeModulePkg/Core/Dxe/Mem/Pool.c
    M MdeModulePkg/MdeModulePkg.dec

  Log Message:
  -----------
  MdeModulePkg: DxeCore: Do Not Apply Guards to Unsupported Types

Currently, there are multiple issues when page or pool guards are
allocated for runtime memory regions that are aligned to
non-EFI_PAGE_SIZE alignments. Multiple other issues have been fixed for
these same systems (notably ARM64 which has a 64k runtime page
allocation granularity) recently. The heap guard system is only built to
support 4k guard pages and 4k alignment.

Today, the address returned to a caller of AllocatePages will not be
aligned correctly to the runtime page allocation granularity, because
the heap guard system does not take non-4k alignment requirements into
consideration.

However, even with this bug fixed, the Memory Allocation Table cannot be
produced and an OS with a larger than 4k page granularity will not have
aligned memory regions because the guard pages are reported as part of
the same memory allocation. So what would have been, on an ARM64 system,
a 64k runtime memory allocation is actually a 72k memory allocation as
tracked by the Page.c code because the guard pages are tracked as part
of the same allocation. This is a core function of the current heap
guard architecture.

This could also be fixed with rearchitecting the heap guard system to
respect alignment requirements and shift the guard pages inside of the
outer rounded allocation or by having guard pages be the runtime
granularity. Both of these approaches have issues. In the former case,
we break UEFI spec 2.10 section 2.3.6 for AARCH64, which states that
each 64k page for runtime memory regions may not have mixed memory
attributes, which pushing the guard pages inside would create. In the
latter case, an immense amount of memory is wasted to support such large
guard pages, and with pool guard many systems could not support an
additional 128k allocation for all runtime memory.

The simpler and safer solution is to disallow page and pool guards for
runtime memory allocations for systems that have a runtime granularity
greater than the EFI_PAGE_SIZE (4k). The usefulness of such guards is
limited, as OSes do not map guard pages today, so there is only boot
time protection of these ranges. This also prevents other bugs from
being exposed by using guards for regions that have a non-4k alignment
requirement, as again, multiple have cropped up because the heap guard
system was not built to support it.

This patch adds both a static assert to ensure that either the runtime
granularity is the EFI_PAGE_SIZE or that the PCD bits are not set to
enable heap guard for runtime memory regions. It also adds a check in
the page and pool allocation system to ensure that at runtime we are not
allocating a runtime region and attempt to guard it (the PCDs are close
to being removed in favor of dynamic heap guard configurations).

BZ: https://bugzilla.tianocore.org/show_bug.cgi?id=4674
Github PR: https://github.com/tianocore/edk2/pull/5382

Cc: Leif Lindholm <quic_llind...@quicinc.com>
Cc: Ard Biesheuvel <ardb+tianoc...@kernel.org>
Cc: Sami Mujawar <sami.muja...@arm.com>
Cc: Liming Gao <gaolim...@byosoft.com.cn>

Signed-off-by: Oliver Smith-Denny <o...@linux.microsoft.com>
Reviewed-by: Liming Gao <gaolim...@byosoft.com.cn>


Compare: https://github.com/tianocore/edk2/compare/5572b43c6767...e7486b50646d

To unsubscribe from these emails, change your notification settings at 
https://github.com/tianocore/edk2/settings/notifications


_______________________________________________
edk2-commits mailing list
edk2-commits@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/edk2-commits

Reply via email to