On 04/04, Jim Keniston wrote:
>
> On Fri, 2014-04-04 at 20:51 +0200, Oleg Nesterov wrote:
> >
> > Currently only adjust_ret_addr() can fail, and this can only happen if
> > another thread unmapped our stack after we executed "call" out-of-line.
> > Most probably the application if buggy, but even in this case it can
> > have a handler for SIGSEGV/etc. And in theory it can be even correct
> > and do something non-trivial with its memory.
> >
> > Of course we can't restart unconditionally, so arch_uprobe_post_xol()
> > does this only if ->post_xol() returns -ERESTART even if currently this
> > is the only possible error.
>
> When re-executing the call instruction, I'd think the stack pointer
> would be wrong the second time around, unless you pop off the return
> address from the first try.
Of course! Like ttt_post_xol_op() in the next patch does, can't understand
how I forgot.
Thanks a lot! Please see v3 below.
I also updated the changelog. Please do not ask me to cleanup the games
with ->sp now. I'll try to do this later when we finish the bug fixes.
The current code should be unified with the code we will add. And I think
that adjust_ret_address() should die. What we need is uprobe_push(), there
is no need for copy_from_user() afaics. The value we need to push is
utask->vaddr + correction-calculated-at-analyze-time.
-------------------------------------------------------------------------------
Subject: [PATCH v3 9/9] uprobes/x86: Teach arch_uprobe_post_xol() to restart if
possible
SIGILL after the failed arch_uprobe_post_xol() should only be used as
a last resort, we should try to restart the probed insn if possible.
Currently only adjust_ret_addr() can fail, and this can only happen if
another thread unmapped our stack after we executed "call" out-of-line.
Most probably the application if buggy, but even in this case it can
have a handler for SIGSEGV/etc. And in theory it can be even correct
and do something non-trivial with its memory.
Of course we can't restart unconditionally, so arch_uprobe_post_xol()
does this only if ->post_xol() returns -ERESTART even if currently this
is the only possible error.
default_post_xol_op(UPROBE_FIX_CALL) can always restart, but as Jim
pointed out it should not forget to pop off the return address pushed
by this insn executed out-of-line.
Note: this is not "perfect", we do not want the extra handler_chain()
after restart, but I think this is the best solution we can realistically
do without too much uglifications.
TODO: This adds yet another is_ia32_task() check, and the next patches
will add more. I will try cleanup this later, after we fix the pending
problems. And to remind, it seems that adjust_ret_addr() should die.
Signed-off-by: Oleg Nesterov <o...@redhat.com>
---
arch/x86/kernel/uprobes.c | 20 ++++++++++++++++----
1 files changed, 16 insertions(+), 4 deletions(-)
diff --git a/arch/x86/kernel/uprobes.c b/arch/x86/kernel/uprobes.c
index e72903e..cdd6909 100644
--- a/arch/x86/kernel/uprobes.c
+++ b/arch/x86/kernel/uprobes.c
@@ -443,16 +443,22 @@ static int default_post_xol_op(struct arch_uprobe
*auprobe, struct pt_regs *regs
{
struct uprobe_task *utask = current->utask;
long correction = (long)(utask->vaddr - utask->xol_vaddr);
- int ret = 0;
handle_riprel_post_xol(auprobe, regs, &correction);
if (auprobe->fixups & UPROBE_FIX_IP)
regs->ip += correction;
- if (auprobe->fixups & UPROBE_FIX_CALL)
- ret = adjust_ret_addr(regs->sp, correction);
+ if (auprobe->fixups & UPROBE_FIX_CALL) {
+ if (adjust_ret_addr(regs->sp, correction)) {
+ if (is_ia32_task())
+ regs->sp += 4;
+ else
+ regs->sp += 8;
+ return -ERESTART;
+ }
+ }
- return ret;
+ return 0;
}
static struct uprobe_xol_ops default_xol_ops = {
@@ -599,6 +605,12 @@ int arch_uprobe_post_xol(struct arch_uprobe *auprobe,
struct pt_regs *regs)
int err = auprobe->ops->post_xol(auprobe, regs);
if (err) {
arch_uprobe_abort_xol(auprobe, regs);
+ /*
+ * Restart the probed insn. ->post_xol() must ensure
+ * this is really possible if it returns -ERESTART.
+ */
+ if (err == -ERESTART)
+ return 0;
return err;
}
}
--
1.5.5.1
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
