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+CK2bB-qPV-QnqUwAv+OGujZwWLAAgBT0xH6fyKY8-cP1bNSQ@mail.gmail.com>
Date: Tue, 25 Mar 2025 10:04:21 -0400
From: Pasha Tatashin <pasha.tatashin@...een.com>
To: Baoquan He <bhe@...hat.com>
Cc: Dave Young <dyoung@...hat.com>, 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, Mar 25, 2025 at 2:58 AM Baoquan He <bhe@...hat.com> wrote:
>
> On 03/24/25 at 12:18pm, Dave Young 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
>
> kho scracth memorys are reserved much later than crashkernel, we may not
> need to worry about it.
> ====================
> start_kernel()
>   ......
>   -->setup_arch(&command_line);
>      -->arch_reserve_crashkernel();
>   ......
>   -->mm_core_init();
>      -->kho_memory_init();
>
> > 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.
>
> Yeah, it's not meaningful to dump out scratch memorys into vmcore. We
> may need to dig them out from eflcorehdr. While it's an optimization,
> kho scratch is not big relative to the entire system memory. It can be
> done in later stage. My personal opinion.

But, we don't; we only dump out the regular CMA memory that absolutely
should be part of vmcore. When scratch is used during boot, it is used
for regular early boot kernel allocations, such as to allocate memmap,
which is an essential part of the crash dump.

Pasha