linux-kernel - Re: [PATCH 07/10] uprobes/x86: Introduce arch_uretprobe_is

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: <20150520165117.GA4284@redhat.com>
Date:	Wed, 20 May 2015 18:51:17 +0200
From:	Oleg Nesterov <oleg@...hat.com>
To:	Srikar Dronamraju <srikar@...ux.vnet.ibm.com>
Cc:	Ananth N Mavinakayanahalli <ananth@...ibm.com>,
	Anton Arapov <arapov@...il.com>,
	David Long <dave.long@...aro.org>,
	Denys Vlasenko <dvlasenk@...hat.com>,
	"Frank Ch. Eigler" <fche@...hat.com>,
	Ingo Molnar <mingo@...nel.org>,
	Jan Willeke <willeke@...ibm.com>,
	Jim Keniston <jkenisto@...ibm.com>,
	Mark Wielaard <mjw@...hat.com>,
	Pratyush Anand <panand@...hat.com>,
	linux-kernel@...r.kernel.org,
	Benjamin Herrenschmidt <benh@...nel.crashing.org>
Subject: Re: [PATCH 07/10] uprobes/x86: Introduce arch_uretprobe_is_alive()

Srikar,

sorry for delay, vacation.

On 05/13, Srikar Dronamraju wrote:
>
> > No. I don't think arch_uretprobe_is_alive() above can work for powerpc,
> > at least the same way.
> >
> > The problem is, when the function is called, the ret-addr is not pushed
> > on stack. If it was, then arch_uretprobe_hijack_return_addr() on powerpc
> > is just wrong. But I guess it is correct ;)
> >
> > x86 is "simple". We know that the probed function should do "ret" and the
> > ret-addr lives on stack. This means that "regs->sp <= sp" is correct, it
> > can't be false-negative. Simply because if regs->sp > sp then *sp can be
> > never used by "ret". And everything above regs->sp can be overwritten by
> > a signal handler. powerpc/etc differs, they use the link register.
> >
>
> In ppc, the return address for the current function may not be in stack
> but in link register, but the return address for the previous functions
> end up in the stack.

Yes, yes, I understand. That is why I hope that this series can help
other arches too ;)

But note that at least this means that the "on_call" arg should be ignored,
although this is not the problem too.

> Lets assume main() had called foo(). Now when foo()
> calls bar (by using the b/bl instruction), we would save the current
> link register (that has address corresponding to main function) to the
> link register save area of the stack and update the stack pointer and
> the link register to an address to where we need to jump back in foo().

Yes. Now suppose that you ret-probe both main() and foo(). What happens
when foo() returns?

I guess it should cleanup the stack and remove the main's ret-addr from
stack, doesn't this mean that arch_uretprobe_is_alive(auret_for_main)
becomes false if we just use user_stack_pointer(regs) <= sp for every arch?
This will break handle_trampoline().

> > So. Lets do this per-arch. Try to do, actually. I am not even sure these
> > new hooks can actually help powerpc/etc. If not, we will have to switch
> > to "plan B".
>
> Okay, lets do it per-arch now and yes it can always be cleaned up later.

Yes, this just looks safer. At least this way we can't introduce the new
problems on !x86.

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/