On Fri, 10 Jan 2025 at 19:12, Usama Arif <usamaarif642@xxxxxxxxx> wrote: > > > > On 10/01/2025 02:50, Dave Young wrote: > > Hi Usama, > > > > On Thu, 9 Jan 2025 at 06:00, Usama Arif <usamaarif642@xxxxxxxxx> wrote: > >> > >> When this area is not reserved, it comes up as usable in > >> /sys/firmware/memmap. This means that kexec, which uses that memmap > >> to find usable memory regions, can select the region where > >> efi_mem_attr_table is and overwrite it and relocate_kernel. > > > > Is the attr table BOOT SERVICE DATA? If so, does efi_mem_reserve() > > work for you? > > Just refer to esrt.c. > > > > Hi Dave, > > Its a bit difficult to reproduce the problem and therefore test the fix, but > we are seeing it a lot in production. Ard proposed the same thing in > https://lore.kernel.org/all/6b4780a5-ada0-405e-9f0a-4d2186177f29@xxxxxxxxx/ > but as I mentioned there, I dont think that efi_mem_reserve would help, > as efi_mem_reserve changes e820_table, while kexec looks at > /sys/firmware/memmap which uses e820_table_firmware. I sent a question to pm people, if the sysfs memmap comes from e820_table then it will be fine. Let's see: https://lore.kernel.org/all/CALu+AoS-nk4u=9UYP7BLS=diOxjJRf+vfv7KHXG=uXozoYazsw@xxxxxxxxxxxxxx/ > > Thanks, > Usama > > > Thanks > > Dave > > >
