linux-kernel - Re: [PATCH v4 00/14] kexec: introduce Kexec HandOver (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: <Z7tgvwRkV-GAtBL_@kernel.org>
Date: Sun, 23 Feb 2025 19:54:07 +0200
From: Mike Rapoport <rppt@...nel.org>
To: Alexander Gordeev <agordeev@...ux.ibm.com>
Cc: Dave Young <dyoung@...hat.com>, Alexander Graf <graf@...zon.com>,
	linux-kernel@...r.kernel.org,
	Andrew Morton <akpm@...ux-foundation.org>,
	Andy Lutomirski <luto@...nel.org>,
	Anthony Yznaga <anthony.yznaga@...cle.com>,
	Arnd Bergmann <arnd@...db.de>, Ashish Kalra <ashish.kalra@....com>,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>,
	Borislav Petkov <bp@...en8.de>,
	Catalin Marinas <catalin.marinas@....com>,
	Dave Hansen <dave.hansen@...ux.intel.com>,
	David Woodhouse <dwmw2@...radead.org>,
	Eric Biederman <ebiederm@...ssion.com>,
	Ingo Molnar <mingo@...hat.com>, James Gowans <jgowans@...zon.com>,
	Jonathan Corbet <corbet@....net>,
	Krzysztof Kozlowski <krzk@...nel.org>,
	Mark Rutland <mark.rutland@....com>,
	Paolo Bonzini <pbonzini@...hat.com>,
	Pasha Tatashin <pasha.tatashin@...een.com>,
	"H. Peter Anvin" <hpa@...or.com>,
	Peter Zijlstra <peterz@...radead.org>,
	Pratyush Yadav <ptyadav@...zon.de>,
	Rob Herring <robh+dt@...nel.org>, Rob Herring <robh@...nel.org>,
	Saravana Kannan <saravanak@...gle.com>,
	Stanislav Kinsburskii <skinsburskii@...ux.microsoft.com>,
	Steven Rostedt <rostedt@...dmis.org>,
	Thomas Gleixner <tglx@...utronix.de>,
	Tom Lendacky <thomas.lendacky@....com>,
	Usama Arif <usama.arif@...edance.com>,
	Will Deacon <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,
	Philipp Rudo <prudo@...hat.com>, Heiko Carstens <hca@...ux.ibm.com>,
	Vasily Gorbik <gor@...ux.ibm.com>,
	Christian Borntraeger <borntraeger@...ux.ibm.com>,
	Sven Schnelle <svens@...ux.ibm.com>, linux-s390@...r.kernel.org
Subject: Re: [PATCH v4 00/14] kexec: introduce Kexec HandOver (KHO)

On Thu, Feb 20, 2025 at 05:43:48PM +0100, Alexander Gordeev wrote:
> On Thu, Feb 20, 2025 at 09:49:52AM +0800, Dave Young wrote:
> > On Wed, 19 Feb 2025 at 21:55, Alexander Graf <graf@...zon.com> wrote:
> > > >>> What architecture exactly does this KHO work fine?   Device Tree
> > > >>> should be ok on arm*, x86 and power*, but how about s390?
> > > >> KHO does not use device tree as the boot protocol, it uses FDT as a data
> > > >> structure and adds architecture specific bits to the boot structures to
> > > >> point to that data, very similar to how IMA_KEXEC works.
> > > >>
> > > >> Currently KHO is implemented on arm64 and x86, but there is no fundamental
> > > >> reason why it wouldn't work on any architecture that supports kexec.
> > > > Well,  the problem is whether there is a way to  add dtb in the early
> > > > boot path,  for X86 it is added via setup_data,  if there is no such
> > > > way I'm not sure if it is doable especially for passing some info for
> > > > early boot use.  Then the KHO will be only for limited use cases.
> > >
> > >
> > > Every architecture has a platform specific way of passing data into the
> > > kernel so it can find its command line and initrd. S390x for example has
> > > struct parmarea. To enable s390x, you would remove some of its padding
> > > and replace it with a KHO base addr + size, so that the new kernel can
> > > find the KHO state tree.
> > 
> > Ok, thanks for the info,  I cced s390 people maybe they can provide inputs.
> 
> If I understand correctly, the parmarea would be used for passing the
> FDT address - which appears to be fine. However, s390 does not implement
> early_memremap()/early_memunmap(), which KHO needs.

KHO uses early_memremap()/early_memunmap() because it parses FDT before
phys_to_virt() is available on arm64 and x86. AFAIU on s390 phys_to_virt()
can be used at setup_arch() time, so it shouldn't be a problem to add
appropriate wrappers.
 
-- 
Sincerely yours,
Mike.