Re: [edk2-devel] [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved region in 820_table_firmware

["Dave Young via groups.io" <dyoung=redhat.com@groups.io>]

On Fri, 10 Jan 2025 at 19:18, Dave Young <dyoung@redhat.com> wrote:
>
> On Fri, 10 Jan 2025 at 19:12, Usama Arif <usamaarif642@gmail.com> wrote:
> >
> >
> >
> > On 10/01/2025 02:50, Dave Young wrote:
> > > Hi Usama,
> > >
> > > On Thu, 9 Jan 2025 at 06:00, Usama Arif <usamaarif642@gmail.com> 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@gmail.com/
> > 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

> https://lore.kernel.org/all/CALu+AoS-nk4u=9UYP7BLS=diOxjJRf+vfv7KHXG=uXozoYazsw@mail.gmail.com/
>
> >
> > Thanks,
> > Usama
> >
> > > Thanks
> > > Dave
> > >
> >



-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#121010): https://edk2.groups.io/g/devel/message/121010
Mute This Topic: https://groups.io/mt/110518541/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-