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  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:   Tue, 22 Jan 2019 17:39:35 +0800
From:   Peter Xu <>
To:     Jerome Glisse <>
        Hugh Dickins <>,
        Maya Gokhale <>,
        Johannes Weiner <>,
        Martin Cracauer <>,
        Denis Plotnikov <>,
        Shaohua Li <>,
        Andrea Arcangeli <>,
        Pavel Emelyanov <>,
        Mike Kravetz <>,
        Marty McFadden <>,
        Mike Rapoport <>,
        Mel Gorman <>,
        "Kirill A . Shutemov" <>,
        "Dr . David Alan Gilbert" <>,
        Rik van Riel <>
Subject: Re: [PATCH RFC 06/24] userfaultfd: wp: support write protection for
 userfault vma range

On Mon, Jan 21, 2019 at 09:05:35AM -0500, Jerome Glisse wrote:


> > +	change_protection(dst_vma, start, start + len, newprot,
> > +				!enable_wp, 0);
> So setting dirty_accountable bring us to that code in mprotect.c:
>     if (dirty_accountable && pte_dirty(ptent) &&
>             (pte_soft_dirty(ptent) ||
>              !(vma->vm_flags & VM_SOFTDIRTY))) {
>         ptent = pte_mkwrite(ptent);
>     }
> My understanding is that you want to set write flag when enable_wp
> is false and you want to set the write flag unconditionaly, right ?


> If so then you should really move the change_protection() flags
> patch before this patch and add a flag for setting pte write flags.
> Otherwise the above is broken at it will only set the write flag
> for pte that were dirty and i am guessing so far you always were
> lucky because pte were all dirty (change_protection will preserve
> dirtyness) when you write protected them.
> So i believe the above is broken or at very least unclear if what
> you really want is to only set write flag to pte that have the
> dirty flag set.

You are right, if we build the tree until this patch it won't work for
all the cases.  It'll only work if the page was at least writable
before and also it's dirty (as you explained).  Sorry to be unclear
about this, maybe I should at least mention that in the commit message
but I totally forgot it.

All these problems are solved in later on patches, please feel free to
have a look at:

  mm: merge parameters for change_protection()
  userfaultfd: wp: apply _PAGE_UFFD_WP bit
  userfaultfd: wp: handle COW properly for uffd-wp

Note that even in the follow up patches IMHO we can't directly change
the write permission since the page can be shared by other processes
(e.g., the zero page or COW pages).  But the general idea is the same
as you explained.

I tried to avoid squashing these stuff altogether as explained
previously.  Also, this patch can be seen as a standalone patch to
introduce the new interface which seems to make sense too, and it is
indeed still working in many cases so I see the latter patches as
enhancement of this one.  Please let me know if you still want me to
have all these stuff squashed, or if you'd like me to squash some of


Peter Xu

Powered by blists - more mailing lists