On Wed, 12 Jul 2023 at 10:41, Gerd Hoffmann <kra...@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 -=-=-=-=-=-=-=-=-=-=-=- Groups.io Links: You receive all messages sent to this group. View/Reply Online (#106854): https://edk2.groups.io/g/devel/message/106854 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] -=-=-=-=-=-=-=-=-=-=-=-
