[PATCH v2 6/6] efi: respect the poisoned pages coming from previous kernel
Kiryl Shutsemau
kas at kernel.org
Mon Aug 24 03:32:35 PDT 2026
On Fri, Aug 21, 2026 at 09:43:37AM -0700, Breno Leitao wrote:
> On Fri, Aug 21, 2026 at 03:53:32PM +0100, Kiryl Shutsemau wrote:
> > On Fri, Aug 21, 2026 at 07:03:06AM -0700, Breno Leitao wrote:
> > > On Fri, Aug 21, 2026 at 01:13:55PM +0100, Kiryl Shutsemau wrote:
> > > > On Fri, Aug 21, 2026 at 03:06:06AM -0700, Breno Leitao wrote:
> > > > > + /* Reserve the table itself so it survives a further kexec. */
> > > > > + memblock_reserve(PAGE_ALIGN_DOWN(ppm),
> > > > > + PAGE_ALIGN(ppm + sizeof(*pm) + bitmap_size) -
> > > > > + PAGE_ALIGN_DOWN(ppm));
> > > >
> > > > Hm. I don't think it is enough.
> > > >
> > > > On x86, kernel doesn't keep memblock around after boot (see
> > > > CONFIG_ARCH_KEEP_MEMBLOCK). Reserving in memblock exclude the memory
> > > > from page allocator. But kexec can place the image there.
> > >
> > > You mean the third kexec?
> > >
> > > 1) Kernel A hits an ECC error and marks page X poisoned.
> > > 2) Kernel A kexecs into kernel B, which won't use that page since
> > > it's in EFI_POISONED_PAGE and memblock-reserved.
> > > 3) Kernel B kexecs into kernel C, which doesn't respect
> > > EFI_POISONED_PAGE.
> > >
> > > Is this the scenario you mean?
> >
> > No. I think nothing prevents kernel B from putting kernel C image into
> > the reserved space in !CONFIG_ARCH_KEEP_MEMBLOCK case.
> >
> > Kernel B excludes poisoned memory from buddy allocator, but kexec
> > doesn't care about this when look for placement for the next image.
>
> Right, that is exactly the case I meant above — sorry for not being
> clearer.
>
> Agreed, this is a gap.
>
> Can we keep it separate for now and address it as a follow-up?
I wounder if the fix would be to make page allocator consume the table
and not do memblock_reserve() here? So we would allocate struct pages
for the memory and poison them on init. And your fix by the link below
would do the rest.
> Similar
> to the one covered the initial issue [1] first.
>
> Link: https://lore.kernel.org/all/20260812-kexec_posioned-v6-0-e477887086f0@debian.org/ [1]
--
Kiryl Shutsemau / Kirill A. Shutemov
More information about the kexec
mailing list