linux-kernel - Re: [PATCH v5 3.1.0-rc4-tip 5/26] Uprobes: copy of the original instruction.

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: <20111005160934.GC806@linux.vnet.ibm.com>
Date:	Wed, 5 Oct 2011 21:39:34 +0530
From:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Peter Zijlstra <peterz@...radead.org>, Ingo Molnar <mingo@...e.hu>,
	Steven Rostedt <rostedt@...dmis.org>,
	Linux-mm <linux-mm@...ck.org>,
	Arnaldo Carvalho de Melo <acme@...radead.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Hugh Dickins <hughd@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Jonathan Corbet <corbet@....net>,
	LKML <linux-kernel@...r.kernel.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Roland McGrath <roland@...k.frob.com>,
	Andi Kleen <andi@...stfloor.org>,
	Andrew Morton <akpm@...ux-foundation.org>
Subject: Re: [PATCH v5 3.1.0-rc4-tip 5/26]   Uprobes: copy of the original
 instruction.

* Oleg Nesterov <oleg@...hat.com> [2011-10-03 18:29:05]:

> On 09/20, Srikar Dronamraju wrote:
> >
> > +static int __copy_insn(struct address_space *mapping,
> > +			struct vm_area_struct *vma, char *insn,
> > +			unsigned long nbytes, unsigned long offset)
> > +{
> > +	struct file *filp = vma->vm_file;
> > +	struct page *page;
> > +	void *vaddr;
> > +	unsigned long off1;
> > +	unsigned long idx;
> > +
> > +	if (!filp)
> > +		return -EINVAL;
> > +
> > +	idx = (unsigned long) (offset >> PAGE_CACHE_SHIFT);
> > +	off1 = offset &= ~PAGE_MASK;
> > +
> > +	/*
> > +	 * Ensure that the page that has the original instruction is
> > +	 * populated and in page-cache.
> > +	 */
> 
> Hmm. But how we can ensure?
> 
> > +	page_cache_sync_readahead(mapping, &filp->f_ra, filp, idx, 1);
> 
> This schedules the i/o,
> 
> > +	page = grab_cache_page(mapping, idx);
> 
> This finds/locks the page in the page-cache,
> 
> > +	if (!page)
> > +		return -ENOMEM;
> > +
> > +	vaddr = kmap_atomic(page);
> > +	memcpy(insn, vaddr + off1, nbytes);
> 
> What if this page is not PageUptodate() ?
> 
> Somehow this assumes that the i/o was already completed, I don't
> understand this.
> 
> But I am starting to think I simply do not understand this change.
> To the point, I do not underestand why do we need copy_insn() at all.
> We are going to replace this page, can't we save/analyze ->insn later
> when we copy the content of the old page? Most probably I missed
> something simple...
> 

Copying the instruction at the time we replace the original instruction
would have been ideal. However there are a few irritants to handle.

 - While inserting the breakpoint, we might find that the original
   instruction to be the breakpoint instruction itself. (This could
   happen if mmap_uprobe were to race with register_uprobe() or somebody
   else like gdb inserted a breakpoint). How do we distinguish if the
   breakpoint instruction was around in the text or somebody inserted a
   breakpoint in that address-space? Since we read from the page-cache,
   we can easily resolve this.

-  On archs like x86, with variable size instructions, the original
   instruction can be across 2 pages. This is because we copy the
   maximum instruction size from the given vaddr into a buffer for
   subsequent analysis. So the copy_insn takes care of getting two pages
   if and when required. 
   Currently the insert and remove breakpoint
   assumes that the instruction size of a breakpoint is the smallest
   size for that architecture. Hence reading/writing to one page in
   write_opcode is good enough.

-  Again on variable instruction size supporting archs, if two
   subsequent instructions are probed, the original instruction if
   copied using get_user_pages might already have a breakpoint included.
   (This shouldnt have any effect on the uprobes though.)

-- 
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/