linux-mm.kvack.org archive mirror
 help / color / mirror / Atom feed
From: Jeff Xu <jeffxu@google.com>
To: "Liam R. Howlett" <Liam.Howlett@oracle.com>,
	Pedro Falcato <pedro.falcato@gmail.com>,
	 Andrew Morton <akpm@linux-foundation.org>,
	Vlastimil Babka <vbabka@suse.cz>,
	 Lorenzo Stoakes <lorenzo.stoakes@oracle.com>,
	linux-mm@kvack.org,  linux-kernel@vger.kernel.org,
	oliver.sang@intel.com,  torvalds@linux-foundation.org,
	jeffxu@google.com,  Michael Ellerman <mpe@ellerman.id.au>,
	Kees Cook <keescook@chromium.org>
Subject: Re: [PATCH v2 2/6] mm/munmap: Replace can_modify_mm with can_modify_vma
Date: Mon, 12 Aug 2024 07:30:00 -0700	[thread overview]
Message-ID: <CALmYWFvURJBgyFw7x5qrL4CqoZjy92NeFAS750XaLxO7o7Cv9A@mail.gmail.com> (raw)
In-Reply-To: <ljhdwgkfzjgdehfjgvdxa4wyxx4d32kpqqz2pwjse65rasuaeo@nncsuq3ku53o>

+ Kees who commented on mseal() series before. Please keep Kees in the
cc for future response to this series.

On Fri, Aug 9, 2024 at 12:25 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
>
> * Pedro Falcato <pedro.falcato@gmail.com> [240809 14:53]:
> > On Fri, Aug 9, 2024 at 5:48 PM Liam R. Howlett <Liam.Howlett@oracle.com> wrote:
> > >
> > > * Liam R. Howlett <Liam.Howlett@oracle.com> [240809 12:15]:
> > > > * Pedro Falcato <pedro.falcato@gmail.com> [240807 17:13]:
> > > > > We were doing an extra mmap tree traversal just to check if the entire
> > > > > range is modifiable. This can be done when we iterate through the VMAs
> > > > > instead.
> > > > >
> > > > > Signed-off-by: Pedro Falcato <pedro.falcato@gmail.com>
> > > > > ---
> > > > >  mm/mmap.c | 13 +------------
> > > > >  mm/vma.c  | 23 ++++++++++++-----------
> > > > >  2 files changed, 13 insertions(+), 23 deletions(-)
> > > > >
> > > > > diff --git a/mm/mmap.c b/mm/mmap.c
> > > > > index 4a9c2329b09..c1c7a7d00f5 100644
> > > > > --- a/mm/mmap.c
> > > > > +++ b/mm/mmap.c
> > > > > @@ -1740,18 +1740,7 @@ int do_vma_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
> > > > >             unsigned long start, unsigned long end, struct list_head *uf,
> > > > >             bool unlock)
> > > > >  {
> > > > > -   struct mm_struct *mm = vma->vm_mm;
> > > > > -
> > > > > -   /*
> > > > > -    * Check if memory is sealed before arch_unmap.
> > > > > -    * Prevent unmapping a sealed VMA.
> > > > > -    * can_modify_mm assumes we have acquired the lock on MM.
> > > > > -    */
> > > > > -   if (unlikely(!can_modify_mm(mm, start, end)))
> > > > > -           return -EPERM;
> > > > > -
> > > > > -   arch_unmap(mm, start, end);
> > > > > -   return do_vmi_align_munmap(vmi, vma, mm, start, end, uf, unlock);
> > > > > +   return do_vmi_align_munmap(vmi, vma, vma->vm_mm, start, end, uf, unlock);
> > > > >  }
> > > > >
> > > > >  /*
> > > > > diff --git a/mm/vma.c b/mm/vma.c
> > > > > index bf0546fe6ea..7a121bcc907 100644
> > > > > --- a/mm/vma.c
> > > > > +++ b/mm/vma.c
> > > > > @@ -712,6 +712,12 @@ do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
> > > > >             if (end < vma->vm_end && mm->map_count >= sysctl_max_map_count)
> > > > >                     goto map_count_exceeded;
> > > > >
> > > > > +           /* Don't bother splitting the VMA if we can't unmap it anyway */
> > > > > +           if (!can_modify_vma(vma)) {
> > > > > +                   error = -EPERM;
> > > > > +                   goto start_split_failed;
> > > > > +           }
> > > > > +
> > > >
> > > > Would this check be better placed in __split_vma()?  It could replace
> > > > both this and the next chunk of code.
> > >
> > > not quite.
> >
> > Yeah, I was going to say that splitting a sealed VMA is okay (and we
> > allow it on mlock and madvise).
>
> splitting a sealed vma wasn't supposed to be okay.. but it is Jeff's
> feature.  Jeff?
>
Splitting a sealed VMA is wrong.
Whoever wants to split a sealed VMA should  answer this question
first: what is the use case for splitting a sealed VMA?

The V2 series doesn't have selftest change which indicates lack of
testing. The out-of-loop check is positioned nearer to the API entry
point and separated from internal business logic, thereby minimizing
the testing requirements. However, as we move the sealing check
further inward and intertwine it with business logic, greater test
coverage becomes necessary to ensure  the correctness of  sealing
is preserved.




-Jeff
















> >
> > >
> > > >
> > > > >             error = __split_vma(vmi, vma, start, 1);
> > > > >             if (error)
> > > > >                     goto start_split_failed;
> > > > > @@ -723,6 +729,11 @@ do_vmi_align_munmap(struct vma_iterator *vmi, struct vm_area_struct *vma,
> > > > >      */
> > > > >     next = vma;
> > > > >     do {
> > > > > +           if (!can_modify_vma(vma)) {
> > > > > +                   error = -EPERM;
> > > > > +                   goto modify_vma_failed;
> > > > > +           }
> > > > > +
> > >
> > > This chunk would need to be moved below the end check so that we catch
> > > full vma unmaps.
> >
> > Why below the end check? I believe we can avoid the split? Is there
> > something I'm missing?
> > But I did find a bug, what I really seem to want is:
> >
> >  +           if (!can_modify_vma(next)) {
>
> Good catch.
>
> > instead of (vma). It's somewhat concerning how the mseal selftests
> > didn't trip on this?
>
> the end check will call split and will fail in there, if you move the
> code as I suggested.
>
> That means, if we aren't splitting, we still have to check the vma, so
> the check is necessary.
>
>


  reply	other threads:[~2024-08-12 14:30 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20240807211309.2729719-1-pedro.falcato@gmail.com>
2024-08-08 23:12 ` [PATCH v2 0/6] mm: Optimize mseal checks Andrew Morton
2024-08-09  0:34   ` Pedro Falcato
2024-08-09  1:02     ` Jeff Xu
2024-08-09 19:34       ` Liam R. Howlett
2024-08-15 22:10       ` Jeff Xu
2024-08-16  1:58         ` Pedro Falcato
2024-08-16 17:07           ` Jeff Xu
2024-08-16 18:09             ` Pedro Falcato
2024-08-16 18:20               ` Jeff Xu
2024-08-16 18:26                 ` Pedro Falcato
2024-08-16 18:42                   ` Jeff Xu
2024-08-16 17:30           ` Jeff Xu
     [not found] ` <20240807211309.2729719-2-pedro.falcato@gmail.com>
2024-08-09  9:57   ` [PATCH v2 1/6] mm: Move can_modify_vma to mm/internal.h Lorenzo Stoakes
     [not found] ` <20240807211309.2729719-5-pedro.falcato@gmail.com>
2024-08-09 16:05   ` [PATCH v2 4/6] mm/mremap: Replace can_modify_mm with can_modify_vma Liam R. Howlett
2024-08-09 18:45     ` Pedro Falcato
2024-08-12 15:22       ` Liam R. Howlett
     [not found] ` <20240807211309.2729719-3-pedro.falcato@gmail.com>
2024-08-09 16:15   ` [PATCH v2 2/6] mm/munmap: " Liam R. Howlett
2024-08-09 16:48     ` Liam R. Howlett
2024-08-09 18:53       ` Pedro Falcato
2024-08-09 19:24         ` Liam R. Howlett
2024-08-12 14:30           ` Jeff Xu [this message]
2024-08-12 16:57             ` Liam R. Howlett
2024-08-12 17:38               ` Jeff Xu
2024-08-12 19:25                 ` Liam R. Howlett
     [not found] ` <20240807211309.2729719-6-pedro.falcato@gmail.com>
2024-08-09 16:27   ` [PATCH v2 5/6] mseal: Replace can_modify_mm_madv with a vma variant Liam R. Howlett
2024-08-15 21:11 ` [PATCH v2 0/6] mm: Optimize mseal checks Jeff Xu

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CALmYWFvURJBgyFw7x5qrL4CqoZjy92NeFAS750XaLxO7o7Cv9A@mail.gmail.com \
    --to=jeffxu@google.com \
    --cc=Liam.Howlett@oracle.com \
    --cc=akpm@linux-foundation.org \
    --cc=keescook@chromium.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=linux-mm@kvack.org \
    --cc=lorenzo.stoakes@oracle.com \
    --cc=mpe@ellerman.id.au \
    --cc=oliver.sang@intel.com \
    --cc=pedro.falcato@gmail.com \
    --cc=torvalds@linux-foundation.org \
    --cc=vbabka@suse.cz \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox