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

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]

Message-ID: <20141022112657.GG30588@node.dhcp.inet.fi>
Date:	Wed, 22 Oct 2014 14:26:57 +0300
From:	"Kirill A. Shutemov" <kirill@...temov.name>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	torvalds@...ux-foundation.org, paulmck@...ux.vnet.ibm.com,
	tglx@...utronix.de, akpm@...ux-foundation.org, riel@...hat.com,
	mgorman@...e.de, oleg@...hat.com, mingo@...hat.com,
	minchan@...nel.org, kamezawa.hiroyu@...fujitsu.com,
	viro@...iv.linux.org.uk, laijs@...fujitsu.com, dave@...olabs.net,
	linux-kernel@...r.kernel.org, linux-mm@...ck.org
Subject: Re: [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
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/