linux-kernel - Re: [RFC PATCH 7/8] mm: secretmem: use AS

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: <c87a4ba0-b9c4-4044-b0c3-c1112601494f@redhat.com>
Date: Wed, 10 Jul 2024 23:14:04 +0200
From: David Hildenbrand <david@...hat.com>
To: Patrick Roy <roypat@...zon.co.uk>, Mike Rapoport <rppt@...nel.org>
Cc: seanjc@...gle.com, pbonzini@...hat.com, akpm@...ux-foundation.org,
 dwmw@...zon.co.uk, tglx@...utronix.de, mingo@...hat.com, bp@...en8.de,
 dave.hansen@...ux.intel.com, x86@...nel.org, hpa@...or.com,
 willy@...radead.org, graf@...zon.com, derekmn@...zon.com,
 kalyazin@...zon.com, kvm@...r.kernel.org, linux-kernel@...r.kernel.org,
 linux-mm@...ck.org, dmatlack@...gle.com, tabba@...gle.com,
 chao.p.peng@...ux.intel.com, xmarcalx@...zon.co.uk,
 James Gowans <jgowans@...zon.com>
Subject: Re: [RFC PATCH 7/8] mm: secretmem: use AS_INACCESSIBLE to prohibit
 GUP

On 10.07.24 11:50, Patrick Roy wrote:
> 
> 
> On 7/10/24 08:32, Mike Rapoport wrote:
>> CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you can confirm the sender and know the content is safe.
>>
>>
>>
>> On Tue, Jul 09, 2024 at 11:09:29PM +0200, David Hildenbrand wrote:
>>> On 09.07.24 15:20, Patrick Roy wrote:
>>>> Inside of vma_is_secretmem and secretmem_mapping, instead of checking
>>>> whether a vm_area_struct/address_space has the secretmem ops structure
>>>> attached to it, check whether the address_space has the AS_INACCESSIBLE
>>>> bit set. Then set the AS_INACCESSIBLE flag for secretmem's
>>>> address_space.
>>>>
>>>> This means that get_user_pages and friends are disables for all
>>>> adress_spaces that set AS_INACCESIBLE. The AS_INACCESSIBLE flag was
>>>> introduced in commit c72ceafbd12c ("mm: Introduce AS_INACCESSIBLE for
>>>> encrypted/confidential memory") specifically for guest_memfd to indicate
>>>> that no reads and writes should ever be done to guest_memfd
>>>> address_spaces. Disallowing gup seems like a reasonable semantic
>>>> extension, and means that potential future mmaps of guest_memfd cannot
>>>> be GUP'd.
>>>>
>>>> Signed-off-by: Patrick Roy <roypat@...zon.co.uk>
>>>> ---
>>>>    include/linux/secretmem.h | 13 +++++++++++--
>>>>    mm/secretmem.c            |  6 +-----
>>>>    2 files changed, 12 insertions(+), 7 deletions(-)
>>>>
>>>> diff --git a/include/linux/secretmem.h b/include/linux/secretmem.h
>>>> index e918f96881f5..886c8f7eb63e 100644
>>>> --- a/include/linux/secretmem.h
>>>> +++ b/include/linux/secretmem.h
>>>> @@ -8,10 +8,19 @@ extern const struct address_space_operations secretmem_aops;
>>>>    static inline bool secretmem_mapping(struct address_space *mapping)
>>>>    {
>>>> -   return mapping->a_ops == &secretmem_aops;
>>>> +   return mapping->flags & AS_INACCESSIBLE;
>>>> +}
>>>> +
>>>> +static inline bool vma_is_secretmem(struct vm_area_struct *vma)
>>>> +{
>>>> +   struct file *file = vma->vm_file;
>>>> +
>>>> +   if (!file)
>>>> +           return false;
>>>> +
>>>> +   return secretmem_mapping(file->f_inode->i_mapping);
>>>>    }
>>>
>>> That sounds wrong. You should leave *secretmem alone and instead have
>>> something like inaccessible_mapping that is used where appropriate.
>>>
>>> vma_is_secretmem() should not suddenly succeed on something that is not
>>> mm/secretmem.c
>>
>> I'm with David here.
>>
> 
> Right, that makes sense. My thinking here was that if memfd_secret and
> potential mappings of guest_memfd have the same behavior wrt GUP, then
> it makes sense to just have them rely on the same checks. But I guess I
> didn't follow that thought to its logical conclusion of renaming the
> "secretmem" checks into "inaccessible" checks and moving them out of
> secretmem.h.
> 
> Or do you mean to just leave secretmem untouched and add separate
> "inaccessible" checks? But then we'd have two different ways of
> disabling GUP for specific VMAs that both rely on checks in exactly the
> same places :/

You can just replace the vma_is_secretmem in relevant places by checks 
if inaccessible address spaces. No need for the additional 
vma_is_secretmem check then.

BUT, as raised in my other reply, I wonder if adding support for 
secretmem in KVM (I assume) would be simpler+cleaner.

> 
>>> --
>>> Cheers,
>>>
>>> David / dhildenb
>>>
>>
>> --
>> Sincerely yours,
>> Mike.
> 

-- 
Cheers,

David / dhildenb