lkml.org 
[lkml]   [2020]   [Dec]   [19]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [PATCH] mm/userfaultfd: fix memory corruption due to writeprotect
    Hello,

    On Fri, Dec 18, 2020 at 08:30:06PM -0800, Nadav Amit wrote:
    > Analyzing this problem indicates that there is a real bug since
    > mmap_lock is only taken for read in mwriteprotect_range(). This might

    Never having to take the mmap_sem for writing, and in turn never
    blocking, in order to modify the pagetables is quite an important
    feature in uffd that justifies uffd instead of mprotect. It's not the
    most important reason to use uffd, but it'd be nice if that guarantee
    would remain also for the UFFDIO_WRITEPROTECT API, not only for the
    other pgtable manipulations.

    > Consider the following scenario with 3 CPUs (cpu2 is not shown):
    >
    > cpu0 cpu1
    > ---- ----
    > userfaultfd_writeprotect()
    > [ write-protecting ]
    > mwriteprotect_range()
    > mmap_read_lock()
    > change_protection()
    > change_protection_range()
    > ...
    > change_pte_range()
    > [ defer TLB flushes]
    > userfaultfd_writeprotect()
    > mmap_read_lock()
    > change_protection()
    > [ write-unprotect ]
    > ...
    > [ unprotect PTE logically ]
    > ...
    > [ page-fault]
    > ...
    > wp_page_copy()
    > [ set new writable page in PTE]

    Can't we check mm_tlb_flush_pending(vma->vm_mm) if MM_CP_UFFD_WP_ALL
    is set and do an explicit (potentially spurious) tlb flush before
    write-unprotect?

    Thanks,
    Andrea

    \
     
     \ /
      Last update: 2020-12-19 20:18    [W:2.414 / U:0.268 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site