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: <CA+CK2bC4PM0JnHOUm7qfpQ=wUhwsYQ-hJ12tTK_7pSWgYk+bhg@mail.gmail.com>
Date: Mon, 24 Mar 2025 15:26:43 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Dave Young <dyoung@...hat.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 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.

> 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.

Pasha