public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Ard Biesheuvel" <ardb@kernel.org>
To: devel@edk2.groups.io, taylor.d.beebe@gmail.com
Cc: Liming Gao <gaoliming@byosoft.com.cn>
Subject: Re: [edk2-devel] [PATCH v1] MdeModulePkg: Fixup MAT Attributes After Splitting EFI Memory Map
Date: Wed, 17 Apr 2024 08:38:42 +0200	[thread overview]
Message-ID: <CAMj1kXGMYOxpAKE_PeL53uLtYAz1YCOxrSwpsLWrAVfvVKWshQ@mail.gmail.com> (raw)
In-Reply-To: <20240417022836.1593-1-taylor.d.beebe@gmail.com>

Hi Taylor,

On Wed, 17 Apr 2024 at 04:28, Taylor Beebe <taylor.d.beebe@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 <gaoliming@byosoft.com.cn>
> Signed-off-by: Taylor Beebe <taylor.d.beebe@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/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-



  reply	other threads:[~2024-04-17  6:38 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2024-04-17  2:28 [edk2-devel] [PATCH v1] MdeModulePkg: Fixup MAT Attributes After Splitting EFI Memory Map Taylor Beebe
2024-04-17  6:38 ` Ard Biesheuvel [this message]
2024-04-17 13:40   ` Oliver Smith-Denny
2024-04-17 14:05     ` Taylor Beebe
2024-04-17 14:09       ` Oliver Smith-Denny
2024-04-17 14:34         ` Taylor Beebe
2024-04-17 16:52           ` Ard Biesheuvel
2024-04-17 21:53             ` Oliver Smith-Denny
2024-04-17 21:41           ` Oliver Smith-Denny
     [not found]           ` <17C72F39F4EB8845.20027@groups.io>
2024-04-17 22:12             ` Oliver Smith-Denny

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-list from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAMj1kXGMYOxpAKE_PeL53uLtYAz1YCOxrSwpsLWrAVfvVKWshQ@mail.gmail.com \
    --to=devel@edk2.groups.io \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox