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: <20250901135615.7601-1-roypat@amazon.co.uk>
Date: Mon, 1 Sep 2025 13:56:17 +0000
From: "Roy, Patrick" <roypat@...zon.co.uk>
To: "rppt@...nel.org" <rppt@...nel.org>
CC: "ackerleytng@...gle.com" <ackerleytng@...gle.com>, "david@...hat.com"
	<david@...hat.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>, "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

Hi Mike,

On Thu, 2025-08-28 at 15:26 +0100, Mike Rapoport wrote:
> On Thu, Aug 28, 2025 at 09:39:19AM +0000, 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>
>> ---
>>  include/linux/pagemap.h   | 16 ++++++++++++++++
>>  include/linux/secretmem.h | 18 ------------------
>>  lib/buildid.c             |  4 ++--
>>  mm/gup.c                  | 14 +++-----------
>>  mm/mlock.c                |  2 +-
>>  mm/secretmem.c            |  6 +-----
>>  6 files changed, 23 insertions(+), 37 deletions(-)
>>
>> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
>> index e918f96881f5..0ae1fb057b3d 100644
>> --- a/include/linux/secretmem.h
>> +++ b/include/linux/secretmem.h
>> @@ -4,28 +4,10 @@
>>
>>  #ifdef CONFIG_SECRETMEM
>>
>> -extern const struct address_space_operations secretmem_aops;
> 
> Please also make secretmem_aops static in mm/secretmem.c

Ack.

>> -static inline bool secretmem_mapping(struct address_space *mapping)
>> -{
>> -     return mapping->a_ops == &secretmem_aops;
>> -}
>> -
> 
> ...
> 
>> diff --git a/mm/gup.c b/mm/gup.c
>> index adffe663594d..8c988e076e5d 100644
>> --- a/mm/gup.c
>> +++ b/mm/gup.c
>> @@ -1234,7 +1234,7 @@ static int check_vma_flags(struct vm_area_struct *vma, unsigned long gup_flags)
>>       if ((gup_flags & FOLL_SPLIT_PMD) && is_vm_hugetlb_page(vma))
>>               return -EOPNOTSUPP;
>>
>> -     if (vma_is_secretmem(vma))
>> +     if (vma_is_no_direct_map(vma))
>>               return -EFAULT;
>>
>>       if (write) {
>> @@ -2751,7 +2751,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>>  {
>>       bool reject_file_backed = false;
>>       struct address_space *mapping;
>> -     bool check_secretmem = false;
>>       unsigned long mapping_flags;
>>
>>       /*
>> @@ -2763,14 +2762,6 @@ static bool gup_fast_folio_allowed(struct folio *folio, unsigned int flags)
>>               reject_file_backed = true;
>>
>>       /* We hold a folio reference, so we can safely access folio fields. */
>> -
>> -     /* secretmem folios are always order-0 folios. */
>> -     if (IS_ENABLED(CONFIG_SECRETMEM) && !folio_test_large(folio))
>> -             check_secretmem = true;
>> -
>> -     if (!reject_file_backed && !check_secretmem)
>> -             return true;
>> -
>>       if (WARN_ON_ONCE(folio_test_slab(folio)))
>>               return false;
> 
> There's a check for hugetlb after this and a comment there mentions
> secretmem, please update that to "mapping with no direct map" or something
> like that.

Ack.

> --
> Sincerely yours,
> Mike.

Thanks,
Patrick