On 10/01/2025 11:20, Dave Young wrote: > On Fri, 10 Jan 2025 at 19:18, Dave Young <dyoung@xxxxxxxxxx> wrote: >> >> 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: > s/e820_table/e820_table_kexec > Do you mean change /sys/firmware/memmap to point to e820_table_kexec instead of e820_table_firmware [1]? I thought of doing this when the first bug was encountered last year, but didn't do it as I thought it would be frowned upon to change what sysfs file exposes to userspace. [1] https://elixir.bootlin.com/linux/v6.12.6/source/arch/x86/kernel/e820.c#L31 >> https://lore.kernel.org/all/CALu+AoS-nk4u=9UYP7BLS=diOxjJRf+vfv7KHXG=uXozoYazsw@xxxxxxxxxxxxxx/ >> >>> >>> Thanks, >>> Usama >>> >>>> Thanks >>>> Dave >>>> >>> >
