linux-kernel - Re: [PATCH v2 11/13] kho: Allow kexec load before KHO finalization

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [day] [month] [year] [list]

Message-ID: <CA+CK2bBg9xpkNyeWVR5+YQhpZYxSvWzB=nXV_d4D+DmzLdSB1A@mail.gmail.com>
Date: Thu, 18 Dec 2025 22:11:37 -0500
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Ricardo Neri <ricardo.neri-calderon@...ux.intel.com>
Cc: akpm@...ux-foundation.org, bhe@...hat.com, rppt@...nel.org, 
	jasonmiu@...gle.com, arnd@...db.de, coxu@...hat.com, dave@...ilevsky.ca, 
	ebiggers@...gle.com, graf@...zon.com, kees@...nel.org, 
	linux-kernel@...r.kernel.org, kexec@...ts.infradead.org, linux-mm@...ck.org, 
	ricardo.neri@...el.com
Subject: Re: [PATCH v2 11/13] kho: Allow kexec load before KHO finalization

On Thu, Dec 18, 2025 at 9:37 PM Ricardo Neri
<ricardo.neri-calderon@...ux.intel.com> wrote:
>
> On Thu, Dec 18, 2025 at 07:26:19PM -0500, Pasha Tatashin wrote:
> > On Thu, Dec 18, 2025 at 4:49 PM Ricardo Neri
> > <ricardo.neri-calderon@...ux.intel.com> wrote:
> > >
> > > On Fri, Nov 14, 2025 at 02:00:00PM -0500, Pasha Tatashin wrote:
> > > > Currently, kho_fill_kimage() checks kho_out.finalized and returns
> > > > early if KHO is not yet finalized. This enforces a strict ordering where
> > > > userspace must finalize KHO *before* loading the kexec image.
> > > >
> > > > This is restrictive, as standard workflows often involve loading the
> > > > target kernel early in the lifecycle and finalizing the state (FDT)
> > > > only immediately before the reboot.
> > > >
> > > > Since the KHO FDT resides at a physical address allocated during boot
> > > > (kho_init), its location is stable. We can attach this stable address
> > > > to the kimage regardless of whether the content has been finalized yet.
> > > >
> > > > Relax the check to only require kho_enable, allowing kexec_file_load
> > > > to proceed at any time.
> > > >
> > > > Signed-off-by: Pasha Tatashin <pasha.tatashin@...een.com>
> > > > Reviewed-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
> > > > Reviewed-by: Pratyush Yadav <pratyush@...nel.org>
> > > > ---
> > > >  kernel/liveupdate/kexec_handover.c | 2 +-
> > > >  1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/kernel/liveupdate/kexec_handover.c b/kernel/liveupdate/kexec_handover.c
> > > > index 461d96084c12..4596e67de832 100644
> > > > --- a/kernel/liveupdate/kexec_handover.c
> > > > +++ b/kernel/liveupdate/kexec_handover.c
> > > > @@ -1550,7 +1550,7 @@ int kho_fill_kimage(struct kimage *image)
> > > >       int err = 0;
> > > >       struct kexec_buf scratch;
> > > >
> > > > -     if (!kho_out.finalized)
> > > > +     if (!kho_enable)
> > > >               return 0;
> > >
> > > Hi Pasha,
> > >
> > > Using v6.19-rc1 (which has this changeset) and with:
> > >
> > > CONFIG_KEXEC_HANDOVER=y
> > > CONFIG_KEXEC_HANDOVER_ENABLE_DEFAULT=y
> > > CONFIG_LIVEUPDATE=n (i.e., nobody calling kho_finalize())
> > > no reserve_mem= entries in the kernel command line
> > >
> > > I omit doing
> > >
> > > echo 1 > /sys/kernel/debug/kho/out/finalize
> > >
> > > before doing
> > >
> > > kexec -l <kernel> --initrd=<initrd> --commandline="$(cat /proc/cmdline)"
> > > kexec -e
> >
> > Hi Ricardo,
> >
> > Thank you for reporting this bug. I created a fix here:
> > https://lore.kernel.org/lkml/20251219002355.3323896-1-pasha.tatashin@soleen.com
> >
> > Please let me know if it works.
>
> Thanks for the quick reply, Pasha. Your patch does work for me (I saw you
> will post a v2).

I have sent v2:
https://lore.kernel.org/lkml/20251219030854.3527871-1-pasha.tatashin@soleen.com

>
> From this patchset, I gather that kho_finalize() can be called multiple
> times and in-kernel users of KHO should call it when done preparing their
> subrees. Is that correct?

This is correct, we now allow it to finalize multiple times. In kernel
users can choose to do that during reboot, we also removed abort.

Pasha