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: <14df1d99-7df0-4982-8029-e66dfb140399@amd.com>
Date: Wed, 26 Nov 2025 16:27:29 -0600
From: "Pratik R. Sampat" <prsampat@....com>
To: Kiryl Shutsemau <kas@...nel.org>
Cc: 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, bp@...en8.de,
 dave.hansen@...ux.intel.com, ardb@...nel.org, akpm@...ux-foundation.org,
 david@...hat.com, osalvador@...e.de, thomas.lendacky@....com,
 michael.roth@....com
Subject: Re: [RFC PATCH 2/4] mm: Add support for unaccepted memory hotplug



On 11/26/25 5:12 AM, Kiryl Shutsemau wrote:
> On Tue, Nov 25, 2025 at 11:57:51AM -0600, Pratik R. Sampat wrote:
>> The unaccepted memory structure currently only supports accepting memory
>> present at boot time. The unaccepted table uses a fixed-size bitmap
>> reserved in memblock based on the initial memory layout, preventing
>> dynamic addition of memory ranges after boot. This causes guest
>> termination when memory is hot-added in a secure virtual machine due to
>> accessing pages that have not transitioned to private before use.
> 
> How does the hot-pluggable memory look in EFI memory map? I thought
> hot-pluggable ranges suppose to be declared thare. The cleanest solution
> would be to have hot-pluggable and unaccepted indicated in EFI memory,
> so we can size bitmap accordingly upfront.
> 

I'm not quite sure if I fully understand. Do you mean to refer to the
EFI_MEMORY_HOT_PLUGGABLE attribute that is used for cold plugged boot
memory? If so, wouldn't it still be desirable to increase the size of
the bitmap to what was marked as hotpluggable initially?

>> Extend the unaccepted memory framework to handle hotplugged memory by
>> dynamically managing the unaccepted bitmap. Allocate a new bitmap when
>> hotplugged ranges exceed the reserved bitmap capacity and switch to
>> kernel-managed allocation.
>>
>> Hotplugged memory also follows the same acceptance policy using the
>> accept_memory=[eager|lazy] kernel parameter to accept memory either
>> up-front when added or before first use.
>>
>> Signed-off-by: Pratik R. Sampat <prsampat@....com>
>> ---
>>  arch/x86/boot/compressed/efi.h                |  1 +
>>  .../firmware/efi/libstub/unaccepted_memory.c  |  1 +
>>  drivers/firmware/efi/unaccepted_memory.c      | 83 +++++++++++++++++++
>>  include/linux/efi.h                           |  1 +
>>  include/linux/mm.h                            | 11 +++
>>  mm/memory_hotplug.c                           |  7 ++
>>  mm/page_alloc.c                               |  2 +
>>  7 files changed, 106 insertions(+)
>>
>> diff --git a/arch/x86/boot/compressed/efi.h b/arch/x86/boot/compressed/efi.h
>> index 4f7027f33def..a220a1966cae 100644
>> --- a/arch/x86/boot/compressed/efi.h
>> +++ b/arch/x86/boot/compressed/efi.h
>> @@ -102,6 +102,7 @@ struct efi_unaccepted_memory {
>>  	u32 unit_size;
>>  	u64 phys_base;
>>  	u64 size;
>> +	bool mem_reserved;
>>  	unsigned long *bitmap;
>>  };
>>  
> 
> Again, this is ABI break for kexec.
> 

Right, maybe I could just use memblock_is_reserved() instead to prevent
this ABI breakage.

Thanks!
--
Pratik