Re: [RFC][PATCH 3/6] mm: VMA sequence count

[Kirill A. Shutemov]

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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/