linux-kernel - Re: [PATCH v2 1/3] mm: introduce new .mmap

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: <CAJuCfpGqGMozrmoKB78htT-o44cj4rhKN3Q4ae_N1Uv1hJ1r5Q@mail.gmail.com>
Date: Tue, 13 May 2025 08:31:35 -0700
From: Suren Baghdasaryan <surenb@...gle.com>
To: David Hildenbrand <david@...hat.com>
Cc: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>, Andrew Morton <akpm@...ux-foundation.org>, 
	"Liam R . Howlett" <Liam.Howlett@...cle.com>, Vlastimil Babka <vbabka@...e.cz>, 
	Mike Rapoport <rppt@...nel.org>, Michal Hocko <mhocko@...e.com>, Jann Horn <jannh@...gle.com>, 
	Pedro Falcato <pfalcato@...e.de>, linux-fsdevel@...r.kernel.org, 
	linux-kernel@...r.kernel.org, linux-mm@...ck.org, 
	Alexander Viro <viro@...iv.linux.org.uk>, Christian Brauner <brauner@...nel.org>, Jan Kara <jack@...e.cz>, 
	Matthew Wilcox <willy@...radead.org>
Subject: Re: [PATCH v2 1/3] mm: introduce new .mmap_prepare() file callback

On Tue, May 13, 2025 at 6:25 AM David Hildenbrand <david@...hat.com> wrote:
>
> On 13.05.25 11:32, Lorenzo Stoakes wrote:
> > On Tue, May 13, 2025 at 11:01:41AM +0200, David Hildenbrand wrote:
> >> On 09.05.25 14:13, Lorenzo Stoakes wrote:
> >>> Provide a means by which drivers can specify which fields of those
> >>> permitted to be changed should be altered to prior to mmap()'ing a
> >>> range (which may either result from a merge or from mapping an entirely new
> >>> VMA).
> >>>
> >>> Doing so is substantially safer than the existing .mmap() calback which
> >>> provides unrestricted access to the part-constructed VMA and permits
> >>> drivers and file systems to do 'creative' things which makes it hard to
> >>> reason about the state of the VMA after the function returns.
> >>>
> >>> The existing .mmap() callback's freedom has caused a great deal of issues,
> >>> especially in error handling, as unwinding the mmap() state has proven to
> >>> be non-trivial and caused significant issues in the past, for instance
> >>> those addressed in commit 5de195060b2e ("mm: resolve faulty mmap_region()
> >>> error path behaviour").
> >>>
> >>> It also necessitates a second attempt at merge once the .mmap() callback
> >>> has completed, which has caused issues in the past, is awkward, adds
> >>> overhead and is difficult to reason about.
> >>>
> >>> The .mmap_prepare() callback eliminates this requirement, as we can update
> >>> fields prior to even attempting the first merge. It is safer, as we heavily
> >>> restrict what can actually be modified, and being invoked very early in the
> >>> mmap() process, error handling can be performed safely with very little
> >>> unwinding of state required.
> >>>
> >>> The .mmap_prepare() and deprecated .mmap() callbacks are mutually
> >>> exclusive, so we permit only one to be invoked at a time.
> >>>
> >>> Update vma userland test stubs to account for changes.
> >>>
> >>> Signed-off-by: Lorenzo Stoakes <lorenzo.stoakes@...cle.com>

Reviewed-by: Suren Baghdasaryan <surenb@...gle.com>

> >>> ---
> >>>    include/linux/fs.h               | 25 ++++++++++++
> >>>    include/linux/mm_types.h         | 24 +++++++++++
> >>>    mm/memory.c                      |  3 +-
> >>>    mm/mmap.c                        |  2 +-
> >>>    mm/vma.c                         | 68 +++++++++++++++++++++++++++++++-
> >>>    tools/testing/vma/vma_internal.h | 66 ++++++++++++++++++++++++++++---
> >>>    6 files changed, 180 insertions(+), 8 deletions(-)
> >>>
> >>> diff --git a/include/linux/fs.h b/include/linux/fs.h
> >>> index 016b0fe1536e..e2721a1ff13d 100644
> >>> --- a/include/linux/fs.h
> >>> +++ b/include/linux/fs.h
> >>> @@ -2169,6 +2169,7 @@ struct file_operations {
> >>>     int (*uring_cmd)(struct io_uring_cmd *ioucmd, unsigned int issue_flags);
> >>>     int (*uring_cmd_iopoll)(struct io_uring_cmd *, struct io_comp_batch *,
> >>>                             unsigned int poll_flags);
> >>> +   int (*mmap_prepare)(struct vm_area_desc *);
> >>>    } __randomize_layout;
> >>>    /* Supports async buffered reads */
> >>> @@ -2238,11 +2239,35 @@ struct inode_operations {
> >>>     struct offset_ctx *(*get_offset_ctx)(struct inode *inode);
> >>>    } ____cacheline_aligned;
> >>> +/* Did the driver provide valid mmap hook configuration? */
> >>> +static inline bool file_has_valid_mmap_hooks(struct file *file)
> >>> +{
> >>> +   bool has_mmap = file->f_op->mmap;
> >>> +   bool has_mmap_prepare = file->f_op->mmap_prepare;
> >>> +
> >>> +   /* Hooks are mutually exclusive. */
> >>> +   if (WARN_ON_ONCE(has_mmap && has_mmap_prepare))
> >>> +           return false;
> >>> +   if (WARN_ON_ONCE(!has_mmap && !has_mmap_prepare))
> >>> +           return false;
> >>> +
> >>> +   return true;
> >>> +}
> >>
> >> So, if neither is set, it's also an invalid setting, understood.
> >>
> >> So we want XOR.
> >>
> >>
> >>
> >> const bool has_mmap = file->f_op->mmap;
> >> const bool has_mmap_prepare = file->f_op->mmap_prepare;
> >> const bool mutual_exclusive = has_mmap ^ has_mmap_prepare;
> >>
> >> WARN_ON_ONCE(!mutual_exclusive)
> >> return mutual_exclusive;
> >
> > Yeah I did consider xor like this but I've always found it quite confusing
> > in this kind of context, honestly.
>
> With the local variable I think it's quite helpful (no need for a
> comment :P ).
>
> >
> > In a way I think it's a bit easier spelt out as it is now. But happy to
> > change if you feel strongly about it? :)
>
> Certainly not strongly! :)
>
> --
> Cheers,
>
> David / dhildenb
>