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 for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <20111003162905.GA3752@redhat.com>
Date:	Mon, 3 Oct 2011 18:29:05 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.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.

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


> +static struct task_struct *get_mm_owner(struct mm_struct *mm)
> +{
> +	struct task_struct *tsk;
> +
> +	rcu_read_lock();
> +	tsk = rcu_dereference(mm->owner);
> +	if (tsk)
> +		get_task_struct(tsk);
> +	rcu_read_unlock();
> +	return tsk;
> +}

Hmm. Do we really need task_struct?

> -static int install_breakpoint(struct mm_struct *mm, struct uprobe *uprobe)
> +static int install_breakpoint(struct mm_struct *mm, struct uprobe *uprobe,
> +				struct vm_area_struct *vma, loff_t vaddr)
>  {
> -	/* Placeholder: Yet to be implemented */
> +	struct task_struct *tsk;
> +	unsigned long addr;
> +	int ret = -EINVAL;
> +
>  	if (!uprobe->consumers)
>  		return 0;
>
> -	atomic_inc(&mm->mm_uprobes_count);
> -	return 0;
> +	tsk = get_mm_owner(mm);
> +	if (!tsk)	/* task is probably exiting; bail-out */
> +		return -ESRCH;
> +
> +	if (vaddr > TASK_SIZE_OF(tsk))
> +		goto put_return;

But this should not be possible, no? How it can map this vaddr above
TASK_SIZE ?

get_user_pages(tsk => NULL) is fine. Why else do we need mm->owner ?

Probably used by the next patches... Say, is_32bit_app(tsk). This
can use mm->context.ia32_compat (hopefully will be replaced with
MMF_COMPAT).

Oleg.

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