[edk2-devel] heap/page guard broken on aarch64

[Oliver Smith-Denny]

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 <kraxel at 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/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-