linux-kernel - Re: [PATCH v5 3.1.0-rc4-tip 12/26] Uprobes: Handle breakpoint and Singlestep

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: <20111007182834.GA1655@redhat.com>
Date:	Fri, 7 Oct 2011 20:28:34 +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>,
	Jonathan Corbet <corbet@....net>,
	Hugh Dickins <hughd@...gle.com>,
	Christoph Hellwig <hch@...radead.org>,
	Masami Hiramatsu <masami.hiramatsu.pt@...achi.com>,
	Thomas Gleixner <tglx@...utronix.de>,
	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Jim Keniston <jkenisto@...ux.vnet.ibm.com>,
	Roland McGrath <roland@...k.frob.com>,
	Andi Kleen <andi@...stfloor.org>,
	LKML <linux-kernel@...r.kernel.org>
Subject: Re: [PATCH v5 3.1.0-rc4-tip 12/26]   Uprobes: Handle breakpoint
	and Singlestep

On 09/20, Srikar Dronamraju wrote:
>
> @@ -1285,6 +1286,9 @@ static struct task_struct *copy_process(unsigned long clone_flags,
>  	INIT_LIST_HEAD(&p->pi_state_list);
>  	p->pi_state_cache = NULL;
>  #endif
> +#ifdef CONFIG_UPROBES
> +	p->utask = NULL;
> +#endif

I am not sure I understand this all right, but I am not sure this
is enough...

What if the forking task (current) is in UTASK_BP_HIT state?

IOW, uprobe replaces the original syscall insn with "int3", then we
enter the kernel from the xol_vma. The new child has the same
modified instruction pointer (pointing to nowhere without CLONE_VM)
and in any case it doesn't have TIF_SINGLESTEP.

No?

> +void uprobe_notify_resume(struct pt_regs *regs)
> +{
> +	struct vm_area_struct *vma;
> +	struct uprobe_task *utask;
> +	struct mm_struct *mm;
> +	struct uprobe *u = NULL;
> +	unsigned long probept;
> +
> +	utask = current->utask;
> +	mm = current->mm;
> +	if (!utask || utask->state == UTASK_BP_HIT) {
> +		probept = get_uprobe_bkpt_addr(regs);
> +		down_read(&mm->mmap_sem);
> +		vma = find_vma(mm, probept);
> +		if (vma && valid_vma(vma))
> +			u = find_uprobe(vma->vm_file->f_mapping->host,
> +					probept - vma->vm_start +
> +					(vma->vm_pgoff << PAGE_SHIFT));
> +		up_read(&mm->mmap_sem);
> +		if (!u)
> +			/* No matching uprobe; signal SIGTRAP. */
> +			goto cleanup_ret;
> +		if (!utask) {
> +			utask = add_utask();
> +			/* Cannot Allocate; re-execute the instruction. */
> +			if (!utask)
> +				goto cleanup_ret;
> +		}
> +		/* TODO Start queueing signals. */
> +		utask->active_uprobe = u;
> +		handler_chain(u, regs);
> +		utask->state = UTASK_SSTEP;
> +		if (!pre_ssout(u, regs, probept))
> +			user_enable_single_step(current);

Oooh. Playing with user_*_single_step() is obviously not very nice...
But I guess you have no choice. Although I _hope_ we can do something
else later.

And what if we step into a syscall insn? I do not understand this
low level code, but it seems that in this case we trap in kernel mode
and do_debug() doesn't clear X86_EFLAGS_TF because uprobes hook
DIE_DEBUG. IOW, the task will trap again and again inside this syscall,
no?

> +	} else if (utask->state == UTASK_SSTEP) {
> +		u = utask->active_uprobe;
> +		if (sstep_complete(u, regs)) {

It is not clear to me if it is correct to simply return if
sstep_complete() returns false... What if X86_EFLAGS_TF was "lost"
somehow?


Again, I am not saying I understand this magic. Not at all ;)
Please simply ignore my email if you think everything is fine.

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/