linux-kernel - Re: [PATCH v4 5/8] x86/mm: Use pagetable

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: <04983c62-3b1d-40d4-93ae-34ca04b827e5@intel.com>
Date: Fri, 5 Sep 2025 13:11:15 -0700
From: Dave Hansen <dave.hansen@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, Lu Baolu <baolu.lu@...ux.intel.com>
Cc: Joerg Roedel <joro@...tes.org>, Will Deacon <will@...nel.org>,
 Robin Murphy <robin.murphy@....com>, Kevin Tian <kevin.tian@...el.com>,
 Jann Horn <jannh@...gle.com>, Vasant Hegde <vasant.hegde@....com>,
 Alistair Popple <apopple@...dia.com>, Peter Zijlstra <peterz@...radead.org>,
 Uladzislau Rezki <urezki@...il.com>,
 Jean-Philippe Brucker <jean-philippe@...aro.org>,
 Andy Lutomirski <luto@...nel.org>, Yi Lai <yi1.lai@...el.com>,
 iommu@...ts.linux.dev, security@...nel.org, linux-kernel@...r.kernel.org
Subject: Re: [PATCH v4 5/8] x86/mm: Use pagetable_free()

On 9/5/25 11:41, Jason Gunthorpe wrote:
>> --- a/arch/x86/mm/init_64.c
>> +++ b/arch/x86/mm/init_64.c
>> @@ -1013,7 +1013,7 @@ static void __meminit free_pagetable(struct page *page, int order)
>>  		free_reserved_pages(page, nr_pages);
>>  #endif
>>  	} else {
>> -		free_pages((unsigned long)page_address(page), order);
>> +		pagetable_free(page_ptdesc(page));
>>  	}
>>  }
> Er.. So if bootmem happens to be under the table and we happen to free
> it due to memory hotplug we don't go through the SVA fixing path?
> 
> Seems wrong??

On second thought...

Yes, freeing bootmem with no SVA fixing is wrong. It should be fixed.
Period. But, it's wrong one time for something super rare: memory unplug
of memory that was present at boot. It also can't be triggered by
unprivileged users.

As-is, this series fixes vfree(). That path is not nearly rare, can
happen an arbitrary number of times on each boot, and might even be
triggered by folks that are less than root.

So I kinda think we should just make clear that this series leaves
_some_ holes, but I do think it should go in mostly as-is.