* heap/page guard broken on aarch64
@ 2023-07-12 8:41 Gerd Hoffmann
2023-07-12 12:03 ` Ard Biesheuvel
0 siblings, 1 reply; 4+ messages in thread
From: Gerd Hoffmann @ 2023-07-12 8:41 UTC (permalink / raw)
To: devel, Ard Biesheuvel
Hi,
Tried to debug a bug which looks like memory corruption, turned on page
and heap guard:
PcdHeapGuardPageType=0x7e
PcdHeapGuardPoolType=0x7e
PcdHeapGuardPropertyMask=0x03
With that the firmware crashes due to a page fault.
Stack trace (with PCs manually mapped to functions):
PC 0x000047730268 (0x000047711000+0x0001F268) [ 0] DxeCore.dll -> InternalMemSetMem
PC 0x00004771F4EC (0x000047711000+0x0000E4EC) [ 0] DxeCore.dll -> CoreConvertPagesEx
PC 0x00004771FED4 (0x000047711000+0x0000EED4) [ 0] DxeCore.dll -> CoreFreePoolPagesI
PC 0x000047721368 (0x000047711000+0x00010368) [ 0] DxeCore.dll -> CoreFreePoolI
PC 0x000047721564 (0x000047711000+0x00010564) [ 0] DxeCore.dll -> CoreInternalFreePool
PC 0x00004772160C (0x000047711000+0x0001060C) [ 0] DxeCore.dll -> CoreFreePool
PC 0x00007C574338 (0x00007C560000+0x00014338) [ 1] VariableRuntimeDxe.dll -> FreePool
PC 0x00007C574F8C (0x00007C560000+0x00014F8C) [ 1] VariableRuntimeDxe.dll -> ReallocateRuntimePool
PC 0x00007C574FE0 (0x00007C560000+0x00014FE0) [ 1] VariableRuntimeDxe.dll -> VarCheckAddTableEntry
PC 0x00007C575FF0 (0x00007C560000+0x00015FF0) [ 1] VariableRuntimeDxe.dll -> VarCheckLibVariablePropertySet
PC 0x00007C5760B8 (0x00007C560000+0x000160B8) [ 1] VariableRuntimeDxe.dll -> VarCheckUefiLibNullClassConstructor
PC 0x00007C578828 (0x00007C560000+0x00018828) [ 1] VariableRuntimeDxe.dll -> _ModuleEntryPoint
PC 0x000047718788 (0x000047711000+0x00007788) [ 2] DxeCore.dll -> CoreStartImage
PC 0x000047725CC8 (0x000047711000+0x00014CC8) [ 2] DxeCore.dll -> CoreDispatcher
PC 0x00004771BFF0 (0x000047711000+0x0000AFF0) [ 2] DxeCore.dll -> _ModuleEntryPoint
Some debug logging added shows that the faulting address is right after
the memory block which gets freed, looks like the code tries to clear
the guard page ...
edk2-stable202305 is broken.
edk2-stable202302 works.
Trying to bisect did not work due to another bug.
take care,
Gerd
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: heap/page guard broken on aarch64
2023-07-12 8:41 heap/page guard broken on aarch64 Gerd Hoffmann
@ 2023-07-12 12:03 ` Ard Biesheuvel
2023-07-12 13:26 ` Gerd Hoffmann
0 siblings, 1 reply; 4+ messages in thread
From: Ard Biesheuvel @ 2023-07-12 12:03 UTC (permalink / raw)
To: Gerd Hoffmann; +Cc: devel
On Wed, 12 Jul 2023 at 10:41, Gerd Hoffmann <kraxel@redhat.com> wrote:
>
> Hi,
>
> Tried to debug a bug which looks like memory corruption, turned on page
> and heap guard:
>
> PcdHeapGuardPageType=0x7e
> PcdHeapGuardPoolType=0x7e
> PcdHeapGuardPropertyMask=0x03
>
> With that the firmware crashes due to a page fault.
>
> Stack trace (with PCs manually mapped to functions):
>
> PC 0x000047730268 (0x000047711000+0x0001F268) [ 0] DxeCore.dll -> InternalMemSetMem
> PC 0x00004771F4EC (0x000047711000+0x0000E4EC) [ 0] DxeCore.dll -> CoreConvertPagesEx
> PC 0x00004771FED4 (0x000047711000+0x0000EED4) [ 0] DxeCore.dll -> CoreFreePoolPagesI
> PC 0x000047721368 (0x000047711000+0x00010368) [ 0] DxeCore.dll -> CoreFreePoolI
> PC 0x000047721564 (0x000047711000+0x00010564) [ 0] DxeCore.dll -> CoreInternalFreePool
> PC 0x00004772160C (0x000047711000+0x0001060C) [ 0] DxeCore.dll -> CoreFreePool
> PC 0x00007C574338 (0x00007C560000+0x00014338) [ 1] VariableRuntimeDxe.dll -> FreePool
> PC 0x00007C574F8C (0x00007C560000+0x00014F8C) [ 1] VariableRuntimeDxe.dll -> ReallocateRuntimePool
> PC 0x00007C574FE0 (0x00007C560000+0x00014FE0) [ 1] VariableRuntimeDxe.dll -> VarCheckAddTableEntry
> PC 0x00007C575FF0 (0x00007C560000+0x00015FF0) [ 1] VariableRuntimeDxe.dll -> VarCheckLibVariablePropertySet
> PC 0x00007C5760B8 (0x00007C560000+0x000160B8) [ 1] VariableRuntimeDxe.dll -> VarCheckUefiLibNullClassConstructor
> PC 0x00007C578828 (0x00007C560000+0x00018828) [ 1] VariableRuntimeDxe.dll -> _ModuleEntryPoint
> PC 0x000047718788 (0x000047711000+0x00007788) [ 2] DxeCore.dll -> CoreStartImage
> PC 0x000047725CC8 (0x000047711000+0x00014CC8) [ 2] DxeCore.dll -> CoreDispatcher
> PC 0x00004771BFF0 (0x000047711000+0x0000AFF0) [ 2] DxeCore.dll -> _ModuleEntryPoint
>
> Some debug logging added shows that the faulting address is right after
> the memory block which gets freed, looks like the code tries to clear
> the guard page ...
>
> edk2-stable202305 is broken.
> edk2-stable202302 works.
> Trying to bisect did not work due to another bug.
>
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.
I'll dig a bit deeper - thanks for the report
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: heap/page guard broken on aarch64
2023-07-12 12:03 ` Ard Biesheuvel
@ 2023-07-12 13:26 ` Gerd Hoffmann
2023-07-12 21:20 ` [edk2-devel] " Oliver Smith-Denny
0 siblings, 1 reply; 4+ messages in thread
From: Gerd Hoffmann @ 2023-07-12 13:26 UTC (permalink / raw)
To: Ard Biesheuvel; +Cc: devel
On Wed, Jul 12, 2023 at 02:03:37PM +0200, Ard Biesheuvel wrote:
> On Wed, 12 Jul 2023 at 10:41, Gerd Hoffmann <kraxel@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.
take care,
Gerd
^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [edk2-devel] heap/page guard broken on aarch64
2023-07-12 13:26 ` Gerd Hoffmann
@ 2023-07-12 21:20 ` Oliver Smith-Denny
0 siblings, 0 replies; 4+ messages in thread
From: Oliver Smith-Denny @ 2023-07-12 21:20 UTC (permalink / raw)
To: devel, kraxel, Ard Biesheuvel
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@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
^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2023-07-12 21:20 UTC | newest]
Thread overview: 4+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2023-07-12 8:41 heap/page guard broken on aarch64 Gerd Hoffmann
2023-07-12 12:03 ` Ard Biesheuvel
2023-07-12 13:26 ` Gerd Hoffmann
2023-07-12 21:20 ` [edk2-devel] " Oliver Smith-Denny
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox