linux-kernel - Re: [PATCH v2 7/11] Uprobes Implementation

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: <20100512142437.GO7426@linux.vnet.ibm.com>
Date:	Wed, 12 May 2010 19:54:37 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Peter Zijlstra <peterz@...radead.org>
Cc:	Oleg Nesterov <oleg@...hat.com>, Ingo Molnar <mingo@...e.hu>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <mhiramat@...hat.com>,
	Randy Dunlap <rdunlap@...otime.net>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Frederic Weisbecker <fweisbec@...il.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	LKML <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>, Mel Gorman <mel@....ul.ie>,
	"Paul E. McKenney" <paulmck@...ux.vnet.ibm.com>,
	Andrea Arcangeli <aarcange@...hat.com>
Subject: Re: [PATCH v2 7/11] Uprobes Implementation

* Peter Zijlstra <peterz@...radead.org> [2010-05-12 13:12:31]:

> On Wed, 2010-05-12 at 16:11 +0530, Srikar Dronamraju wrote:
> > > We can't hold mmap_sem (for either read or write -- read would be
> > > sufficient to serialize against mmap/mremap/munmap) from atomic uprobe
> > > context, what we can do is validate that there is a INT3 on that
> > > particular address, a mremap/munmap/munmap+mmap will either end not
> > > having a pte entry for the address, or not have the INT3.
> > 
> > Did you mean "We can hold mmap_sem?" Else I am not sure if we can
> > traverse the vma. Infact alloc_page_vma() needs mmap_sem to be acquired.
> > Please clarify? 
> 
> OK, so maybe I misunderstood, this is from the INT3 trap handler, right?


If I am right, the initial comment was both from the unregister_uprobe()
-> write_opcode() context  and uprobe_bkpt_notifier context.

[ snipping relevant part of Oleg's mail from where the conversation started ]
---------------------------------------------------------------------
> > 4. mremap(). What if the application does mremap() and moves the                                                                      
> >    memory? After that vaddr of user_bkpt/uprobe no longer matches                                                                     
> >    the virtual address of bp. This breaks uprobe_bkpt_notifier(),                                                                     
> >    unregister_uprobe(), etc.                                                                                                          
> >                                                                                                                                       
> >    Even worse. Say, unregister_uprobe() calls remove_bkpt().                                                                          
> >    mremap()+mmap() can be called after ->read_opcode() verifies
> >    vaddr                                                                 
> >    points to bkpt_insn, but before write_opcode() changes the page.     
---------------------------------------------------------------------

But yes, if the mmap/mremap/munmap can happen between validating the
int3 and removal of the breakpoint in the unregister_uprobe path, then
it can as well happen between the breakpoint hit and the time uprobes
does the fixups to continue execution after running the handler and
single-stepping. 

I agree with you that we shouldnt bother about mmap/mremap/munmap of the
executable code. Probably we could document the same.

> 
> We can _not_ take a sleeping lock from trap context. Why would you want
> the vma anyway?

Yes, we dont look at the vma in trap context at all. If we need to allocate a
slot in the xol_vma then we set the TIF_UPROBE do the stuff in task
context.

--
Thanks and Regards
Srikar
> 
--
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/