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: <etd7r45wmnuoftpckrzkzithr443ru6akgwqjgzw2vgmzqi7cs@camfecdmef74>
Date: Wed, 3 Dec 2025 14:46:23 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: "David Hildenbrand (Red Hat)" <david@...nel.org>, ardb@...nel.org
Cc: Borislav Petkov <bp@...en8.de>, "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, akpm@...ux-foundation.org, 
	osalvador@...e.de, thomas.lendacky@....com, michael.roth@....com, 
	torvalds@...ux-foundation.org
Subject: Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug

On Mon, Dec 01, 2025 at 09:36:58PM +0100, David Hildenbrand (Red Hat) wrote:
> On 12/1/25 21:25, Borislav Petkov wrote:
> > On Mon, Dec 01, 2025 at 09:10:26PM +0100, David Hildenbrand (Red Hat) wrote:
> > > Just to be clear, I don't think it exist and also I don't think that it
> > > should exist.
> > 
> > By that logic if it doesn't exist and someone sends a patch, I should simply
> > ignore a review comment about that patch breaking some non-existent ABI and
> > simply take it.
> 
> Well, we can always discuss and see if there is a way to not break a
> specific use case, independent of any ABI stability guarantees.

There is also the #1 Kernel Rule: "we do not break users."

Booting a different version of the kernel is a core functionality of
kexec. It is widely used to deploy new kernels or revert to older ones.
Breaking this functionality is a show-stopper for most, if not all,
hyperscalers.

This specific change may not be a show-stopper as CoCo deployment is not
widespread enough to be noticed yet.

The notion that nobody promised that you can kexec into a different kernel
is absurd. It is used everywhere.

> > 
> > Well, it certainly works for me.
> > 
> > Unless you folks come-a-runnin' later screaming it broke some use case of
> > yours.
> 
> Heh, not me, but likely some of the CoCo folks regarding this specific use
> case (kexec in a confidential VM).
> 
> > And then we're back to what I've been preaching on this thread from the
> > very beginning: having a common agreement on what ABI Linux enforces.
> 
> Right. Maybe Kiryl knows more about this specific case as he brought up that
> these structures are versioned.

I am not involved in the deployment of CoCo VMs, but I don't believe it
is specifically about CoCo or the kexec ABI. I think it is more about
the boot protocol. Kexec is one way to boot the kernel.

Should we consider the EFI configuration tables format as part of the
boot protocol? I believe the answer is "yes," at least for some of them,
like LINUX_EFI_INITRD_MEDIA_GUID.

I also think LINUX_EFI_UNACCEPTED_MEM_TABLE_GUID should be considered in
the same way.

Ard, do you have any comments on this?

-- 
  Kiryl Shutsemau / Kirill A. Shutemov