Re: [PATCH] x86/efi: defer freeing of boot services memory

["Ard Biesheuvel" <ardb@kernel.org>]

On Mon, 23 Feb 2026, at 12:40, Mike Rapoport wrote:
> On Mon, Feb 23, 2026 at 12:17:22PM +0100, Ard Biesheuvel wrote:
>> 
>> On Mon, 23 Feb 2026, at 11:55, Mike Rapoport wrote:
>> > Hi Ard,
>> >
>> > On Mon, Feb 23, 2026 at 09:08:29AM +0100, Ard Biesheuvel wrote:
>> >> Hi Mike,
>> >> 
>> >> On Mon, 23 Feb 2026, at 08:52, Mike Rapoport wrote:
>> >> > From: "Mike Rapoport (Microsoft)" <rppt@kernel.org>
>> >> >
>> >> > efi_free_boot_services() frees memory occupied by EFI_BOOT_SERVICES_CODE
>> >> > and EFI_BOOT_SERVICES_DATA using memblock_free_late().
>> >> >
>> >> > There are two issue with that: memblock_free_late() should be used for
>> >> > memory allocated with memblock_alloc() while the memory reserved with
>> >> > memblock_reserve() should be freed with free_reserved_area().
>> >> >
>> >> > More acutely, with CONFIG_DEFERRED_STRUCT_PAGE_INIT=y
>> >> > efi_free_boot_services() is called before deferred initialization of the
>> >> > memory map is complete.
>> >> >
>> >> > Benjamin Herrenschmidt reports that this causes a leak of ~140MB of
>> >> > RAM on EC2 t3a.nano instances which only have 512MB or RAM.
>> >> >
>> >> > If the freed memory resides in the areas that memory map for them is
>> >> > still uninitialized, they won't be actually freed because
>> >> > memblock_free_late() calls memblock_free_pages() and the latter skips
>> >> > uninitialized pages.
>> >> >
>> >> > Using free_reserved_area() at this point is also problematic because
>> >> > __free_page() accesses the buddy of the freed page and that again might
>> >> > end up in uninitialized part of the memory map.
>> >> >
>> >> > Delaying the entire efi_free_boot_services() could be problematic
>> >> > because in addition to freeing boot services memory it updates
>> >> > efi.memmap without any synchronization and that's undesirable late in
>> >> > boot when there is concurrency.
>> >> >
>> >> > More robust approach is to only defer freeing of the EFI boot services
>> >> > memory.
>> >> >
>> >> > Make efi_free_boot_services() collect ranges that should be freed into
>> >> > an array and add an initcall efi_free_boot_services_memory() that walks
>> >> > that array and actually frees the memory using free_reserved_area().
>> >> >
>> >> 
>> >> Instead of creating another table, could we just traverse the EFI memory
>> >> map again in the arch_initcall(), and free all boot services code/data
>> >> above 1M with EFI_MEMORY_RUNTIME cleared ?
>> > 
>> > Currently efi_free_boot_services() unmaps all boot services code/data with
>> > EFI_MEMORY_RUNTIME cleared and removes them from the efi.memmap.
>> 
>> Ah yes, I failed to spot that those entries are long gone by initcall
>> time. Other architectures don't touch the EFI memory map at all, but x86
>> mangles it beyond recognition :-)
>
> Heh, EFI on x86 does a lot of, hmm, interesting things with memory, like
> memremaping kmalloced memory and I it really begs for cleanups :)
> 

Yeah. Sadly, all this has become ABI for kexec, so the EFI memory map abuse is hard to fix.

>> > I wasn't sure it's Ok to only unmap them, but leave in efi.memmap, that's
>> > why I didn't use the existing EFI memory map.
>> >
>> > Now thinking about it, if the unmapping can happen later, maybe we'll just
>> > move the entire efi_free_boot_services() to an initcall?
>> >
>> 
>> As long as it is pre-SMP, as that code also contains a quirk to allocate
>> the real mode trampoline if all memory below 1 MB is used for boot
>> services.
>
> initcall is long after SMP. It the real mode trampoline allocation is the
> only thing that should happen pre-SMP?
> 

early_initcall() should be early enough, those run before SMP init.

>> But actually, that should be a separate quirk to begin with, rather than
>> being integrated into an unrelated function that happens to iterate over
>> the boot services regions. The only problem, I guess, is that
>> memblock_reserve()'ing that sub-1MB region in the old location in the
>> ordinary way would cause it to be freed again in the initcall?
>
> Right now we anyway don't free anything below 1M, I don't see why it should
> change. 
>
>> But yes, in general I think it is fine to unmap those regions from the
>> EFI page tables during an initcall.
>
> Thanks for confirming. I'll look into extracting the allocation of the real
> mode trampoline to a separate quirk and then making the entire
> efi_free_boot_services() an initcall.
>

Thanks!