linux-kernel - Re: [PATCH] userfaultfd: Write protect when virtual memory range has no page table entry

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]

Date:   Mon, 22 Mar 2021 09:27:30 -0400
From:   Peter Xu <peterx@...hat.com>
To:     Mike Rapoport <rppt@...nel.org>
Cc:     Michal Hocko <mhocko@...e.com>,
        Bui Quang Minh <minhquangbui99@...il.com>,
        akpm@...ux-foundation.org, linux-mm@...ck.org,
        linux-kernel@...r.kernel.org,
        Andrea Arcangeli <aarcange@...hat.com>,
        Axel Rasmussen <axelrasmussen@...gle.com>
Subject: Re: [PATCH] userfaultfd: Write protect when virtual memory range has
 no page table entry

On Mon, Mar 22, 2021 at 03:00:37PM +0200, Mike Rapoport wrote:
> On Mon, Mar 22, 2021 at 11:14:37AM +0100, Michal Hocko wrote:
> > Le'ts Andrea and Mike
> > 
> > On Fri 19-03-21 22:24:28, Bui Quang Minh wrote:
> > > userfaultfd_writeprotect() use change_protection() to clear write bit in
> > > page table entries (pte/pmd). So, later write to this virtual address
> > > range causes a page fault, which is then handled by userspace program.
> > > However, change_protection() has no effect when there is no page table
> > > entries associated with that virtual memory range (a newly mapped memory
> > > range). As a result, later access to that memory range causes allocating a
> > > page table entry with write bit still set (due to VM_WRITE flag in
> > > vma->vm_flags).
> > > 
> > > Add checks for VM_UFFD_WP in vma->vm_flags when allocating new page table
> > > entry in missing page table entry page fault path.
> > 
> > From the above it is not really clear whether this is a usability
> > problem or a bug of the interface.
> 
> I'd say it's usability/documentation clarity issue. 
> Userspace can register an area with
> 
> 	UFFDIO_REGISTER_MODE_MISSING | UFFDIO_REGISTER_MODE_WP
> 
> and then it will be notified either when page table has no entry for a
> virtual address or when there is a write to a write protected address.

Right, it's debatable to make it a default behavior since there can be some
application that does not care about zero pages - since currently userfaultfd
wr-protect only works for anonymous page, so any missing entry means a zero
page to be allocated.

Currently if we want to wr-protect all pages including zero pages, we can
either do as what Mike suggested, or one can pre-read the range to fault in the
pages.  The double-mode solution should be even better, since then the user app
would have a chance to know it's zero page without even scanning it.

It'll be a new story for page-cache backed memory regions, and that's indeed
the major work contained in the upcoming shmem+hugetlbfs uffd-wp support series
[1] to allow persisting uffd-wp/write bit even without page table entries,
because then the entry can be null even when there's page cache (so it'll
bypass uffdio missing messages too).

If this behavior is very desired, how about define a new feature bit, say
UFFD_FEATURE_WP_UNALLOCATED?  This could be more efficient than registering
with two modes, since we can do the later UFFDIO_COPY along with the MISSING
page fault as in this patch, meanwhile that'll also contain the same semantic
as UFFDIO_ZEROCOPY so less data copy too (UFFDIO_ZEROCOPY does not support
UFFDIO_COPY_MODE_WP so far).  However we need to be careful on mixture use of
these, e.g., I think UFFD_FEATURE_WP_UNALLOCATED at least shouldn't be allowed
with UFFDIO_REGISTER_MODE_MISSING, otherwise the behavior of missing fault on
uffd-wp area will be undefined.

Thoughts?

[1] https://lore.kernel.org/lkml/20210115170907.24498-1-peterx@redhat.com/

Thanks,

-- 
Peter Xu