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] -=-=-=-=-=-=-=-=-=-=-=-