linux-kernel - Re: [PATCH v5 11/16] kexec: add config option for KHO

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] [thread-next>] [day] [month] [year] [list]

Message-ID: <CALu+AoRL+oHW2vN8nf1wpsG2Ki8d44AABQRCBMd+CE4_XzqRTw@mail.gmail.com>
Date: Tue, 25 Mar 2025 09:24:02 +0800
From: Dave Young <dyoung@...hat.com>
To: Pasha Tatashin <pasha.tatashin@...een.com>
Cc: Changyuan Lyu <changyuanl@...gle.com>, linux-kernel@...r.kernel.org, graf@...zon.com, 
	akpm@...ux-foundation.org, luto@...nel.org, anthony.yznaga@...cle.com, 
	arnd@...db.de, ashish.kalra@....com, benh@...nel.crashing.org, bp@...en8.de, 
	catalin.marinas@....com, dave.hansen@...ux.intel.com, dwmw2@...radead.org, 
	ebiederm@...ssion.com, mingo@...hat.com, jgowans@...zon.com, corbet@....net, 
	krzk@...nel.org, rppt@...nel.org, mark.rutland@....com, pbonzini@...hat.com, 
	hpa@...or.com, peterz@...radead.org, ptyadav@...zon.de, robh+dt@...nel.org, 
	robh@...nel.org, saravanak@...gle.com, skinsburskii@...ux.microsoft.com, 
	rostedt@...dmis.org, tglx@...utronix.de, thomas.lendacky@....com, 
	usama.arif@...edance.com, will@...nel.org, devicetree@...r.kernel.org, 
	kexec@...ts.infradead.org, linux-arm-kernel@...ts.infradead.org, 
	linux-doc@...r.kernel.org, linux-mm@...ck.org, x86@...nel.org
Subject: Re: [PATCH v5 11/16] kexec: add config option for KHO

On Tue, 25 Mar 2025 at 03:27, Pasha Tatashin <pasha.tatashin@...een.com> wrote:
>
> On Mon, Mar 24, 2025 at 12:18 AM Dave Young <dyoung@...hat.com> wrote:
> >
> > On Thu, 20 Mar 2025 at 23:05, Changyuan Lyu <changyuanl@...gle.com> wrote:
> > >
> > > From: Alexander Graf <graf@...zon.com>
> > >
> > > We have all generic code in place now to support Kexec with KHO. This
> > > patch adds a config option that depends on architecture support to
> > > enable KHO support.
> > >
> > > Signed-off-by: Alexander Graf <graf@...zon.com>
> > > Co-developed-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
> > > Signed-off-by: Mike Rapoport (Microsoft) <rppt@...nel.org>
> > > Co-developed-by: Changyuan Lyu <changyuanl@...gle.com>
> > > Signed-off-by: Changyuan Lyu <changyuanl@...gle.com>
> > > ---
> > >  kernel/Kconfig.kexec | 15 +++++++++++++++
> > >  1 file changed, 15 insertions(+)
> > >
> > > diff --git a/kernel/Kconfig.kexec b/kernel/Kconfig.kexec
> > > index 4d111f871951..57db99e758a8 100644
> > > --- a/kernel/Kconfig.kexec
> > > +++ b/kernel/Kconfig.kexec
> > > @@ -95,6 +95,21 @@ config KEXEC_JUMP
> > >           Jump between original kernel and kexeced kernel and invoke
> > >           code in physical address mode via KEXEC
> > >
> > > +config KEXEC_HANDOVER
> > > +       bool "kexec handover"
> > > +       depends on ARCH_SUPPORTS_KEXEC_HANDOVER && ARCH_SUPPORTS_KEXEC_FILE
> > > +       select MEMBLOCK_KHO_SCRATCH
> > > +       select KEXEC_FILE
> > > +       select DEBUG_FS
> > > +       select LIBFDT
> > > +       select CMA
> > > +       select XXHASH
> > > +       help
> > > +         Allow kexec to hand over state across kernels by generating and
> > > +         passing additional metadata to the target kernel. This is useful
> > > +         to keep data or state alive across the kexec. For this to work,
> > > +         both source and target kernels need to have this option enabled.
> > > +
> >
> > Have you tested kdump?  In my mind there are two issues,  one is with
> > CMA enabled, it could cause kdump crashkernel memory reservation
> > failures more often due to the fragmented low memory.  Secondly,  in
>
> As I understand cma low memory scratch reservation is needed only to
> support some legacy pci devices that cannot use the full 64-bit space.
> If so, I am not sure if KHO needs to be supported on machines with
> such devices. However, even if we keep it, it should really be small,
> so I would not expect that to be a problem for crash kernel memory
> reservation.

It is not easy to estimate how much of the KHO reserved memory is
needed.  I assume this as a mechanism for all different users, it is
not  predictable.  Also it is not only about the size, but also it
makes the memory fragmented.

>
> > kdump kernel dump the crazy scratch memory in vmcore is not very
> > meaningful.  Otherwise I suspect this is not tested under kdump.  If
> > so please disable this option for kdump.
>
> The scratch memory will appear as regular CMA in the vmcore. The crash
> kernel can be kexec loaded only from userland, long after the scratch
> memory is converted to CMA.

Depending on the reserved size, if big enough it should be excluded in
vmcore dumping.
Otherwise if it is a kdump kernel it should skip the handling of the
KHO passed previous old states.

>
> Pasha
>