linux-kernel - Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug

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: <47927c25-a317-488a-823f-ac0588f4eee4@kernel.org>
Date: Mon, 1 Dec 2025 10:18:37 +0100
From: "David Hildenbrand (Red Hat)" <david@...nel.org>
To: Borislav Petkov <bp@...en8.de>
Cc: Kiryl Shutsemau <kas@...nel.org>, "Pratik R. Sampat" <prsampat@....com>,
 linux-mm@...ck.org, linux-coco@...ts.linux.dev, linux-efi@...r.kernel.org,
 x86@...nel.org, linux-kernel@...r.kernel.org, tglx@...utronix.de,
 mingo@...hat.com, dave.hansen@...ux.intel.com, ardb@...nel.org,
 akpm@...ux-foundation.org, osalvador@...e.de, thomas.lendacky@....com,
 michael.roth@....com
Subject: Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug

On 11/28/25 12:34, Borislav Petkov wrote:
> On Fri, Nov 28, 2025 at 10:30:15AM +0100, David Hildenbrand (Red Hat) wrote:
>> kexecing the same kernel is typically used for kdump purposes.
>>
>> kexecing different kernels is used for all sorts of things (live-upgrade,
>> grub-emu come to mind). It's quite common to kexec different kernels, or
>> maybe I misunderstood the question here?
> 
> And my question is: since when do we enforce no-ABI-changes between kernels so
> that we can kexec any kernel into any kernel?
> 
> By that logic I should be able to kexec 5.x into 6.x. I'll bet some money that
> it won't work.

I *think* ordinary kexec would likely work, as I recall that it doesn't 
need a lot of that special kexec ABI sauce like unaccepted memory uses.

Within confidential VMs (kexec ...) I am pretty sure that it's a 
different discussion.

> 
> So unless it is written down somewhere, I think we should probably talk first
> what we want to support and why...
> 
> Makes sense?

Makes sense to me, especially for confidential VMs where we pass such 
kernel-managed data from the old to the new kernel.

-- 
Cheers

David