linux-kernel - Re: [PATCH v4 01/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: <12b82997-0129-4fef-afc0-e925e542be88@suse.cz>
Date: Mon, 3 Mar 2025 10:29:34 +0100
From: Vlastimil Babka <vbabka@...e.cz>
To: David Hildenbrand <david@...hat.com>, Patrick Roy <roypat@...zon.co.uk>,
 rppt@...nel.org, seanjc@...gle.com
Cc: pbonzini@...hat.com, corbet@....net, willy@...radead.org,
 akpm@...ux-foundation.org, song@...nel.org, jolsa@...nel.org,
 ast@...nel.org, daniel@...earbox.net, andrii@...nel.org,
 martin.lau@...ux.dev, eddyz87@...il.com, yonghong.song@...ux.dev,
 john.fastabend@...il.com, kpsingh@...nel.org, sdf@...ichev.me,
 haoluo@...gle.com, Liam.Howlett@...cle.com, lorenzo.stoakes@...cle.com,
 jannh@...gle.com, shuah@...nel.org, kvm@...r.kernel.org,
 linux-doc@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-fsdevel@...r.kernel.org, linux-mm@...ck.org, bpf@...r.kernel.org,
 linux-kselftest@...r.kernel.org, tabba@...gle.com, jgowans@...zon.com,
 graf@...zon.com, kalyazin@...zon.com, xmarcalx@...zon.com,
 derekmn@...zon.com, jthoughton@...gle.com
Subject: Re: [PATCH v4 01/12] mm: introduce AS_NO_DIRECT_MAP

On 2/25/25 17:52, David Hildenbrand wrote:
> On 21.02.25 17:07, Patrick Roy 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.
>> 
>> 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 gfp_t mapping_gfp_mask(struct address_space * mapping)
>>   {
>>   	return mapping->gfp_mask;
>> diff --git a/lib/buildid.c b/lib/buildid.c
>> index c4b0f376fb34..80b5d805067f 100644
>> --- a/lib/buildid.c
>> +++ b/lib/buildid.c
>> @@ -65,8 +65,8 @@ static int freader_get_folio(struct freader *r, loff_t file_off)
>>   
>>   	freader_put_folio(r);
>>   
>> -	/* reject secretmem folios created with memfd_secret() */
>> -	if (secretmem_mapping(r->file->f_mapping))
>> +	/* reject secretmem folios created with memfd_secret() or guest_memfd() */
>> +	if (secretmem_mapping(r->file->f_mapping) || mapping_no_direct_map(r->file->f_mapping))
>>   		return -EFAULT;
> 
> Maybe I'm missing it, but why do we have to special-case secretmem with 
> that at all anymore?
> 
> Couldn't we just let secretmem set AS_NO_DIRECT_MAP as well, and convert 
> all/most secretmem specific stuff to check AS_NO_DIRECT_MAP as well?

That's done in patch 02. But yeah, squashing them together would reduce some
churn. I guess because it removes some !IS_ENABLED(CONFIG_SECRETMEM)
optimizations, a separate change for review was preferred.