[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALu+AoSKrzcvP_wCRqPLO1+VBZzt-kuspiFf3dax8WDMDtCMgg@mail.gmail.com>
Date: Fri, 10 Jan 2025 19:18:12 +0800
From: Dave Young <dyoung@...hat.com>
To: Usama Arif <usamaarif642@...il.com>
Cc: linux-efi@...r.kernel.org, devel@...2.groups.io, kexec@...ts.infradead.org,
ardb@...nel.org, hannes@...xchg.org, x86@...nel.org,
linux-kernel@...r.kernel.org, leitao@...ian.org, gourry@...rry.net,
kernel-team@...a.com
Subject: Re: [RFC 2/2] efi/memattr: add efi_mem_attr_table as a reserved
region in 820_table_firmware
On Fri, 10 Jan 2025 at 19:12, Usama Arif <usamaarif642@...il.com> wrote:
>
>
>
> On 10/01/2025 02:50, Dave Young wrote:
> > Hi Usama,
> >
> > On Thu, 9 Jan 2025 at 06:00, Usama Arif <usamaarif642@...il.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:
https://lore.kernel.org/all/CALu+AoS-nk4u=9UYP7BLS=diOxjJRf+vfv7KHXG=uXozoYazsw@mail.gmail.com/
>
> Thanks,
> Usama
>
> > Thanks
> > Dave
> >
>
Powered by blists - more mailing lists