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] [day] [month] [year] [list]

Message-ID: <928e1004-231d-4dfa-a7fd-0ae2d0e13616@amd.com>
Date: Wed, 14 Jan 2026 16:56:57 -0600
From: "Pratik R. Sampat" <prsampat@....com>
To: Kiryl Shutsemau <kas@...nel.org>
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 1/14/26 4:47 AM, Kiryl Shutsemau wrote:
> On Tue, Jan 13, 2026 at 12:22:33PM -0600, Pratik R. Sampat wrote:
>>
>>
>> On 1/13/26 11:53 AM, Kiryl Shutsemau wrote:
>>> 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.
>>
>> Putting more thought into it, memory unacceptance on remove may be required
>> after all at least for SNP platforms.
>>
>> Consider a scenario:
>> * Guest accepts a GPA say G1, mapped to a host physical address H1.
>> * We attempt to hot-remove the memory. If the guest does not unaccept the memory
>>   now then G1 to H1 mapping within the RMP will still exist.
>> * Then if the hypervisor later hot-adds the memory to G1, it will be now mapped
>>   to H3 and this new mapping will be accepted.
>>
>> This will essentially mean that we have 2 RMP entries: One for H1 and another
>> for H3 mapped for G1 which are both validated / accepted which can then be
>> swapped at will and compromise integrity.
> 
> I don't know much about SEV, but I assume RMP is similar to PAMT in TDX
> where TDX module maintains metadata for host physical memory.
> 
> What side problems do you for guest here?
> 
> I probably miss something, but it seems to be VMM problem, no? I mean if
> VMM doesn't update RMP on replacing one HPA to another for the GPA, it
> is bug in VMM housekeeping. Guest is not responsible for this.
> 

Right, the problem is that we do not inherently trust the host to make change.
That is why in my understanding, the guest is responsible for validating and
rescinding those pages.

--Pratik