linux-kernel - Re: [PATCH v2 11/11] mm: Remove device private pages from the physical address space

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: <20260123135050.GV1134360@nvidia.com>
Date: Fri, 23 Jan 2026 09:50:50 -0400
From: Jason Gunthorpe <jgg@...dia.com>
To: Alistair Popple <apopple@...dia.com>
Cc: Zi Yan <ziy@...dia.com>, Jordan Niethe <jniethe@...dia.com>,
	linux-mm@...ck.org, balbirs@...dia.com, matthew.brost@...el.com,
	akpm@...ux-foundation.org, linux-kernel@...r.kernel.org,
	dri-devel@...ts.freedesktop.org, david@...hat.com,
	lorenzo.stoakes@...cle.com, lyude@...hat.com, dakr@...nel.org,
	airlied@...il.com, simona@...ll.ch, rcampbell@...dia.com,
	mpenttil@...hat.com, willy@...radead.org,
	linuxppc-dev@...ts.ozlabs.org, intel-xe@...ts.freedesktop.org,
	Felix.Kuehling@....com
Subject: Re: [PATCH v2 11/11] mm: Remove device private pages from the
 physical address space

On Fri, Jan 23, 2026 at 04:38:49PM +1100, Alistair Popple wrote:
> > >> We need to be a bit careful by what we mean when we say "HMM" in the kernel.
> > >>
> > >> Specifically MIGRATE_PFN_SHIFT is used with migrate_vma/migrate_device, which
> > >> is the migration half of "HMM" which does depend on CONFIG_DEVICE_MIGRATION or
> > >> really just CONFIG_ZONE_DEVICE making it somewhat arch specific.
> > >>
> > >> However hmm_range_fault() does something similar - see the definition of
> > >> hmm_pfn_flags - it actually steals the top 11 bits of a pfn for flags, and it is
> > >> not architecture specific. It only depends on CONFIG_MMU.
> > >
> > > Oh, that is hacky. But are HMM PFNs with any flag exposed to code outside HMM?
> > > Currently, device private needs to reserve PFNs for struct page, so I assume
> > > only the reserved PFNs are seen by outsiders. Otherwise, when outsiders see
> > > a HMM PFN with a flag, pfn_to_page() on such a PFN will read non exist
> > > struct page, right?
> 
> Any user of hmm_range_fault() would be exposed to an issue - most users of
> hmm_range_fault() use it to grab a PFN (ie. physical address) to map into some
> remote page table. So potentially if some important bit in the PFN is dropped
> that could potentially result in users mapping the wrong physical address or
> page.

Trim the quotes guys..

hmm is arguably returning phys_addr_t >> PAGE_SHIFT. This is a lossless
translation because everything is aligned, it isn't hacky.

The value it returns is not a "pfn", it is a hmm structure that has to
be decoded to something else using a hmm helper function.

I think we take a number of liberties going between pte, phys_addr_t,
pfn. If there are arches that use a special encoding for the mm PFN
then range_fault would need to call converter functions to get to/from
phys_addr_t.

Jason