lkml.org 
[lkml]   [2014]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 3/6] mm: VMA sequence count
    On Mon, Oct 20, 2014 at 11:56:36PM +0200, Peter Zijlstra wrote:
    > Wrap the VMA modifications (vma_adjust/unmap_page_range) with sequence
    > counts such that we can easily test if a VMA is changed.
    >
    > The unmap_page_range() one allows us to make assumptions about
    > page-tables; when we find the seqcount hasn't changed we can assume
    > page-tables are still valid.
    >
    > The flip side is that we cannot distinguish between a vma_adjust() and
    > the unmap_page_range() -- where with the former we could have
    > re-checked the vma bounds against the address.

    You only took care about changing size of VMA or unmap. What about other
    aspects of VMA. How would you care about race with mprotect(2)?

    CPU0 CPU1
    mprotect()
    mprotect_fixup()
    vma_merge()
    [ maybe update vm_sequence ]
    [ page fault kicks in ]
    do_anonymous_page()
    entry = mk_pte(page, fe->vma->vm_page_prot);
    vma_set_page_prot(vma)
    [ update vma->vm_page_prot ]
    change_protection()
    pte_map_lock()
    [ vm_sequence is ok ]
    set_pte_at(entry) // With old vm_page_prot!!!

    This can end up a security issue.

    This particular case can be fixed pretty easily: we should move
    vm_page_prot reference under the ptl and make sure that we walk over
    virtual addresses in same (direct) order everywhere (this is seems true).

    But who knows what else we're missing?

    --
    Kirill A. Shutemov


    \
     
     \ /
      Last update: 2014-10-22 14:01    [W:2.402 / U:0.092 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site