linux-kernel - Re: [PATCH v4 06/14] kexec: Add KHO parsing support

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: <20250210205004.GD3765641@nvidia.com>
Date: Mon, 10 Feb 2025 16:50:04 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Mike Rapoport <rppt@...nel.org>
Cc: linux-kernel@...r.kernel.org, Alexander Graf <graf@...zon.com>,
	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
Subject: Re: [PATCH v4 06/14] kexec: Add KHO parsing support

On Thu, Feb 06, 2025 at 03:27:46PM +0200, Mike Rapoport wrote:

> +/**
> + * kho_claim_mem - Notify the kernel that a handed over memory range is now
> + * in use
> + * @mem: memory range that was preserved during kexec handover
> + *
> + * A kernel subsystem preserved that range during handover and it is going
> + * to reuse this range after kexec. The pages in the range are treated as
> + * allocated, but not %PG_reserved.
> + *
> + * Return: virtual address of the preserved memory range
> + */
> +void *kho_claim_mem(const struct kho_mem *mem)
> +{
> +	unsigned long start_pfn, end_pfn, pfn;
> +	void *va = __va(mem->addr);
> +
> +	start_pfn = PFN_DOWN(mem->addr);
> +	end_pfn = PFN_UP(mem->addr + mem->size);
> +
> +	for (pfn = start_pfn; pfn < end_pfn; pfn++) {
> +		int err = kho_claim_pfn(pfn);
> +
> +		if (err)
> +			return NULL;
> +	}
> +
> +	return va;
> +}
> +EXPORT_SYMBOL_GPL(kho_claim_mem);

I think this is not the sort of interface toward drivers we should be
going for, I think we should be round tripping folios at their
allocated order and when restored the folio should freed with
folio_put(), just like in the normal way. Here you are breaking down
high order folios and undoing the GFP_COMP, it is not desirable for
drivers..

Eventually with some kind of support for conserving the memdesc
struct/page metadata if a driver is using it.

Following that basic primitive you'd want to have the same idea to
preserve kmalloc() memory.

And like I said elsewhere, the drivers should be working on naked
phys_addr_t's stored in their own structs in their own way, not
special kho_mem things.. It won't scale like this if the driver needs
to pass thousands of pages.

Also, how is the driver supposed to figure out what the structure is
inside the kho_mem anyhow? I would expect the FDT key/value store to
have a key/phys_addr_t structure outlining the various driver data
structures.

IMHO this links to my frist comment on how the FDT represents the
preserved memory, it seems thsat FDT format cannot effectively
preserve folios..

Jason