linux-kernel - Re: [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory after hot-remove

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: <aWaGBandNCLT93Tm@thinkstation>
Date: Tue, 13 Jan 2026 17:53:35 +0000
From: Kiryl Shutsemau <kas@...nel.org>
To: "Pratik R. Sampat" <prsampat@....com>
Cc: linux-mm@...ck.org, linux-coco@...ts.linux.dev, x86@...nel.org, 
	linux-kernel@...r.kernel.org, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de, 
	dave.hansen@...ux.intel.com, ardb@...nel.org, akpm@...ux-foundation.org, david@...nel.org, 
	osalvador@...e.de, thomas.lendacky@....com, michael.roth@....com
Subject: Re: [PATCH v2 2/2] mm/memory_hotplug: Add support to unaccept memory
 after hot-remove

On Tue, Jan 13, 2026 at 11:10:21AM -0600, Pratik R. Sampat wrote:
> 
> 
> On 1/13/2026 4:28 AM, Kiryl Shutsemau wrote:
> > On Mon, Jan 12, 2026 at 02:23:00PM -0600, Pratik R. Sampat wrote:
> > > Transition memory to the shared state during a hot-remove operation so
> > > that it can be re-used by the hypervisor. This also applies when memory
> > > is intended to be hotplugged back in later, as those pages will need to
> > > be re-accepted after crossing the trust boundary.
> > 
> > Hm. What happens when we hot-remove memory that was there at the boot
> > and there's bitmap space for it?
> > 
> 
> While hotplug ranges gotten from SRAT don't seem to overlap with the
> conventional ranges in the unaccepted table, EFI_MEMORY_HOT_PLUGGABLE
> attribute could indicate boot time memory that could be hot-removed. I
> could potentially unset the bitmap first, if the bit exists and then
> unaccept.
> 
> Similarly, I could also check if the bitmap is large enough to set the
> bit before I call arch_accept_memory() (This may not really be needed
> though).
> 
> > Also, I'm not sure why it is needed. At least in TDX case, VMM can pull
> > the memory from under guest at any time without a warning. Coverting
> > memory to shared shouldn't make a difference as along as re-adding the
> > same GPA range triggers accept.
> > 
> 
> That makes sense. The only scenario where we could run into trouble on
> SNP platforms is when we redo a qemu device_add after a device_del
> without first removing the memory object entirely since same-state
> transitions result in guest termination.
> 
> This means we must always follow a device_del with an object_del on
> removal. Otherwise, the onus would then be on the VMM to transition
> the memory back to shared before re-adding it to the guest.

This seems to be one-of-many possible ways of VMM to get guest terminated.
DoS is not in something confidential computing aims to prevent.

> However, if this flow is not a concern to begin with then I could
> probably just drop this patch?

Yes, please.

-- 
  Kiryl Shutsemau / Kirill A. Shutemov