Hi Taylor,
On Wed, 17 Apr 2024 at 04:28, Taylor Beebe <taylor.d.be...@gmail.com> wrote:
>
> 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).
>
> Cc: Liming Gao <gaolim...@byosoft.com.cn>
> Signed-off-by: Taylor Beebe <taylor.d.be...@gmail.com>
> ---
> MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c | 29 ++++++++++----------
> 1 file changed, 15 insertions(+), 14 deletions(-)
>
> diff --git a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> index e9343a2c4e..1d9f935db0 100644
> --- a/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> +++ b/MdeModulePkg/Core/Dxe/Misc/MemoryAttributesTable.c
> @@ -425,8 +425,8 @@ MergeMemoryMap (
> }
>
> /**
> - Enforce memory map attributes.
> - This function will set
> EfiRuntimeServicesData/EfiMemoryMappedIO/EfiMemoryMappedIOPortSpace to be
> EFI_MEMORY_XP.
> + Walk the memory map and set
> EfiRuntimeServicesData/EfiMemoryMappedIO/EfiMemoryMappedIOPortSpace
> + to EFI_MEMORY_XP and EfiRuntimeServicesCode to EFI_MEMORY_RO.
>
> @param MemoryMap A pointer to the buffer in which firmware
> places
> the current memory map.
> @@ -447,18 +447,19 @@ EnforceMemoryMapAttribute (
> MemoryMapEntry = MemoryMap;
> MemoryMapEnd = (EFI_MEMORY_DESCRIPTOR *)((UINT8 *)MemoryMap +
> MemoryMapSize);
> while ((UINTN)MemoryMapEntry < (UINTN)MemoryMapEnd) {
> - switch (MemoryMapEntry->Type) {
> - case EfiRuntimeServicesCode:
> - // do nothing
> - break;
> - case EfiRuntimeServicesData:
> - case EfiMemoryMappedIO:
> - case EfiMemoryMappedIOPortSpace:
> - MemoryMapEntry->Attribute |= EFI_MEMORY_XP;
> - break;
> - case EfiReservedMemoryType:
> - case EfiACPIMemoryNVS:
> - break;
> + if ((MemoryMapEntry->Attribute & EFI_MEMORY_ACCESS_MASK) == 0) {
> + switch (MemoryMapEntry->Type) {
> + case EfiRuntimeServicesCode:
> + MemoryMapEntry->Attribute |= EFI_MEMORY_RO;
I'm not sure this is safe. If EFI_MEMORY_RO is not set, it might be intentional.
Note that the purpose of the MAT is primarily to describe permission
attributes that are more granular than the entry itself. Originally,
we tried to split those in the memory map but that broke
SetVirtualAddressMap() so we were forced to add a second table
instead.
For entries where we lack such additional metadata, I don't think we
can make assumptions based on the type beyond mapping data and MMIO
regions XP. We have no idea how those EfiRuntimeServicesCode regions
may be used, and currently, the spec permits RWX semantics for those
if no restrictions are specified.
The spec suggests that omitting an entry from the MAT is the same as
listing it with RO|XP cleared. How RO|XP from the original entry
should be interpreted wrt to the MAT is unspecified. So I think the
only thing we can do at this point is preserve the entry if it has
RO|XP set, or just drop it otherwise.
Note that the spec also mentions that the MAT must only contain
EfiRuntimeServicesCode or EfiRuntimeServicesData entries, and it looks
like this is not being enforced either.
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#117895): https://edk2.groups.io/g/devel/message/117895
Mute This Topic: https://groups.io/mt/105570114/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
