public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
From: "Marvin Häuser" <mhaeuser@posteo.de>
To: Ard Biesheuvel <ardb@kernel.org>
Cc: devel@edk2.groups.io, t@taylorbeebe.com
Subject: Re: [edk2-devel] [PATCH 4/4] ArmPkg/CpuDxe: Implement EFI memory attributes protocol
Date: Tue,  7 Feb 2023 10:13:44 +0000	[thread overview]
Message-ID: <A151225E-4A06-4E14-BAA0-C0BB8169E204@posteo.de> (raw)
In-Reply-To: <CAMj1kXFBddpr38yQ7t1oD3-M5tZMgQH+_5YzLSdcWis3s0eGbg@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 1263 bytes --]


> On 7. Feb 2023, at 11:01, Ard Biesheuvel <ardb@kernel.org> wrote:
> 
> Actually, it seems UnprotectUefiImage () is corrent under the
> assumption that all code regions have EFI_MEMORY_XP cleared by
> default.
> 
> However, if you redefine the policy to set EFI_MEMORY_XP on code
> regions by default, and only permit execution after remapping the code
> read-only explicitly, and only then clearing EFI_MEMORY_XP, that
> routine should revert the region to EFI_MEMORY_XP. But given the
> existing ASSERT()s on having EFI_MEMORY_XP cleared for all code
> regions, the code as it is currently is not incorrect.

Right. My main issue is, it’s nowhere documented that manually changed permissions must be restored to their default before freeing. Within DxeCore, this is easily done using the PCDs, but outside (say you allocate a trampoline buffer and then free it), you would need to manually query the permissions, store them, and restore later.

I did *not* look into the implementation code in detail, but does the new memory permission protocol impose the same constraint implementation-wise and if so, is this documented anywhere?

PS: Fetched the wrong link in my last mail: https://lkml.org/lkml/2022/12/15/352

Best regards,
Marvin

[-- Attachment #2: Type: text/html, Size: 1870 bytes --]

  reply	other threads:[~2023-02-07 10:13 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-31 22:35 [PATCH 0/4] ArmPkg: implement EFI memory attributes protocol Ard Biesheuvel
2023-01-31 22:35 ` [PATCH 1/4] MdePkg: Add Memory Attribute Protocol definition Ard Biesheuvel
2023-02-02  3:19   ` 回复: " gaoliming
2023-02-02  9:25     ` [edk2-devel] " Ard Biesheuvel
2023-01-31 22:35 ` [PATCH 2/4] MdePkg: Bump implemented UEFI version to v2.10 Ard Biesheuvel
2023-02-01  0:10   ` Michael D Kinney
2023-02-01  7:54     ` Ard Biesheuvel
2023-01-31 22:35 ` [PATCH 3/4] ArmPkg/CpuDxe: Unify PageAttributeToGcdAttribute helper Ard Biesheuvel
2023-01-31 22:35 ` [PATCH 4/4] ArmPkg/CpuDxe: Implement EFI memory attributes protocol Ard Biesheuvel
2023-02-01 18:41   ` [edk2-devel] " Taylor Beebe
2023-02-02  9:43     ` Ard Biesheuvel
2023-02-03 19:08       ` Taylor Beebe
2023-02-03 19:58         ` Marvin Häuser
2023-02-07  1:18           ` Taylor Beebe
2023-02-07  8:29             ` Ard Biesheuvel
2023-02-07  8:56               ` Marvin Häuser
2023-02-07  9:16                 ` Ard Biesheuvel
2023-02-07 10:00                   ` Marvin Häuser
2023-02-07 10:01                   ` Ard Biesheuvel
2023-02-07 10:13                     ` Marvin Häuser [this message]
2023-02-07 17:56                       ` Ard Biesheuvel
2023-02-07 18:19                         ` Taylor Beebe
2023-02-07 18:50                           ` Marvin Häuser
2023-02-07 18:19                         ` Marvin Häuser

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=A151225E-4A06-4E14-BAA0-C0BB8169E204@posteo.de \
    --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