On 7/12/2023 6:26 AM, Gerd Hoffmann wrote:
On Wed, Jul 12, 2023 at 02:03:37PM +0200, Ard Biesheuvel wrote:
On Wed, 12 Jul 2023 at 10:41, Gerd Hoffmann <kra...@redhat.com> wrote:
PcdHeapGuardPageType=0x7e
PcdHeapGuardPoolType=0x7e
This looks like the debug 'poison' value is applied to the freed guard
page before the EFI_MEMORY_RP permission is removed.
I wonder if the 'IsGuarded' logic in CoreFreePoolI is wrong here: this
is runtime memory, which is rounded up to 64k granularity on AArch64,
and I would not be surprised if that code is buggy.
Looks plausible to me. Tried fix AdjustPoolHeadF() to use granularity
instead of efi page size, that alone didn't make the firmware boot
though.
Clearing the two runtime memory type bits (0x7e -> 0x1e) makes the
firmware boot.
I haven't had a chance to look at this further yet, but this seems
related to an issue I saw, where legitimate EFI_MEMORY_RP pages will
crash in CoreFreePoolI on release builds, because we don't clear
EFI_MEMORY_RP and that function attempts to read the page (on debug
builds, we do set the DEBUG_CLEAR_MEMORY bit and so clear
EFI_MEMORY_RP before the pool mgmt code tries to read it).
Likely, we should be clearing EFI_MEMORY_RP from pool managed memory
in all cases. It is an odd use case and I was debugging a different
bug that was causing memory to accidentally get marked EFI_MEMORY_RP,
but still, it seems to be a latent bug.
Thanks,
Oliver
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#106886): https://edk2.groups.io/g/devel/message/106886
Mute This Topic: https://groups.io/mt/100096124/21656
Group Owner: devel+ow...@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
