linux-kernel - Re: [PATCH v5 03/12] mm: introduce AS_NO_DIRECT

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: <20250901140305.14081-1-roypat@amazon.co.uk>
Date: Mon, 1 Sep 2025 14:03:06 +0000
From: "Roy, Patrick" <roypat@...zon.co.uk>
To: "david@...hat.com" <david@...hat.com>
CC: "ackerleytng@...gle.com" <ackerleytng@...gle.com>, "Manwaring, Derek"
	<derekmn@...zon.com>, "Thomson, Jack" <jackabt@...zon.co.uk>, "Kalyazin,
 Nikita" <kalyazin@...zon.co.uk>, "kvm@...r.kernel.org" <kvm@...r.kernel.org>,
	"kvmarm@...ts.linux.dev" <kvmarm@...ts.linux.dev>,
	"linux-arm-kernel@...ts.infradead.org"
	<linux-arm-kernel@...ts.infradead.org>, "linux-kernel@...r.kernel.org"
	<linux-kernel@...r.kernel.org>, "linux-mm@...ck.org" <linux-mm@...ck.org>,
	"pbonzini@...hat.com" <pbonzini@...hat.com>, "Roy, Patrick"
	<roypat@...zon.co.uk>, "rppt@...nel.org" <rppt@...nel.org>,
	"seanjc@...gle.com" <seanjc@...gle.com>, "tabba@...gle.com"
	<tabba@...gle.com>, "vbabka@...e.cz" <vbabka@...e.cz>, "will@...nel.org"
	<will@...nel.org>, "Cali, Marco" <xmarcalx@...zon.co.uk>
Subject: Re: [PATCH v5 03/12] mm: introduce AS_NO_DIRECT_MAP


On Thu, 2025-08-28 at 22:00 +0100, David Hildenbrand wrote:
> On 28.08.25 11:39, Roy, Patrick wrote:
>> Add AS_NO_DIRECT_MAP for mappings where direct map entries of folios are
>> set to not present . Currently, mappings that match this description are
>> secretmem mappings (memfd_secret()). Later, some guest_memfd
>> configurations will also fall into this category.
>>
>> Reject this new type of mappings in all locations that currently reject
>> secretmem mappings, on the assumption that if secretmem mappings are
>> rejected somewhere, it is precisely because of an inability to deal with
>> folios without direct map entries, and then make memfd_secret() use
>> AS_NO_DIRECT_MAP on its address_space to drop its special
>> vma_is_secretmem()/secretmem_mapping() checks.
>>
>> This drops a optimization in gup_fast_folio_allowed() where
>> secretmem_mapping() was only called if CONFIG_SECRETMEM=y. secretmem is
>> enabled by default since commit b758fe6df50d ("mm/secretmem: make it on
>> by default"), so the secretmem check did not actually end up elided in
>> most cases anymore anyway.
>>
>> Use a new flag instead of overloading AS_INACCESSIBLE (which is already
>> set by guest_memfd) because not all guest_memfd mappings will end up
>> being direct map removed (e.g. in pKVM setups, parts of guest_memfd that
>> can be mapped to userspace should also be GUP-able, and generally not
>> have restrictions on who can access it).
>>
>> Signed-off-by: Patrick Roy <roypat@...zon.co.uk>
>> ---
> [...]
> 
>> +static inline bool vma_is_no_direct_map(const struct vm_area_struct *vma)
>> +{
>> +     return vma->vm_file && mapping_no_direct_map(vma->vm_file->f_mapping);
>> +}
>> +
> 
> "vma_is_no_direct_map" reads a bit weird.
> 
> "vma_has_no_direct_map" or "vma_no_direct_mapping" might be better.

I went with "vma_has_no_direct_map" for now, because vma_no_direct_mapping
would imply (to me at least) changing "mapping_no_direct_map" to
"mapping_no_direct_mapping", which also reads a bit weird imo.

> With the comment Mike and Fuad raised, this LGTM.
> 
> 
> -- 
> Cheers
> 
> David / dhildenb

Best,
Patrick