linux-kernel - RE: [PATCH v2 1/1] iommu/sva: Invalidate KVA range on kernel TLB flush

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: <BN9PR11MB5276141D37C09E9898F4AE518C4BA@BN9PR11MB5276.namprd11.prod.outlook.com>
Date: Fri, 11 Jul 2025 02:54:17 +0000
From: "Tian, Kevin" <kevin.tian@...el.com>
To: "Hansen, Dave" <dave.hansen@...el.com>, Jason Gunthorpe <jgg@...dia.com>
CC: Baolu Lu <baolu.lu@...ux.intel.com>, Joerg Roedel <joro@...tes.org>, "Will
 Deacon" <will@...nel.org>, Robin Murphy <robin.murphy@....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>, "Lai, Yi1" <yi1.lai@...el.com>,
	"iommu@...ts.linux.dev" <iommu@...ts.linux.dev>, "security@...nel.org"
	<security@...nel.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "stable@...r.kernel.org"
	<stable@...r.kernel.org>
Subject: RE: [PATCH v2 1/1] iommu/sva: Invalidate KVA range on kernel TLB
 flush

> From: Tian, Kevin
> Sent: Friday, July 11, 2025 10:46 AM
> 
> > From: Hansen, Dave <dave.hansen@...el.com>
> > Sent: Thursday, July 10, 2025 11:26 PM
> >
> > On 7/10/25 06:22, Jason Gunthorpe wrote:
> > >> Why does this matter? We flush the CPU TLB in a bunch of different
> ways,
> > >> _especially_ when it's being done for kernel mappings. For example,
> > >> __flush_tlb_all() is a non-ranged kernel flush which has a completely
> > >> parallel implementation with flush_tlb_kernel_range(). Call sites that
> > >> use _it_ are unaffected by the patch here.
> > >>
> > >> Basically, if we're only worried about vmalloc/vfree freeing page
> > >> tables, then this patch is OK. If the problem is bigger than that, then
> > >> we need a more comprehensive patch.
> > > I think we are worried about any place that frees page tables.
> >
> > The two places that come to mind are the remove_memory() code and
> > __change_page_attr().
> >
> > The remove_memory() gunk is in arch/x86/mm/init_64.c. It has a few sites
> > that do flush_tlb_all(). Now that I'm looking at it, there look to be
> > some races between freeing page tables pages and flushing the TLB. But,
> > basically, if you stick to the sites in there that do flush_tlb_all()
> > after free_pagetable(), you should be good.
> >
> 
> Isn't doing flush after free_pagetable() leaving a small window for attack?
> the page table is freed and may have been repurposed while the stale
> paging structure cache still treats it as a page table page...
> 
> looks it's not unusual to see similar pattern in other mm code:
> 
> vmemmap_split_pmd()
> {
> 	if (likely(pmd_leaf(*pmd))) {
> 		...
> 	} else {
> 		pte_free_kernel(&init_mm, pgtable);
> 	}
> 	...
> }

oh, please ignore this comment. It's not about freeing the existing
page table. incautious look. 😊