Uprobes patches.

Move Macro W to asm/insn.h

Macro W used to know if the instructions are valid for user-space/kernel space. This macro is used by kprobes and user_bkpt. (i.e user space breakpoint assistance layer.) So moving it to a common header file asm/insn.h.

Quoted 6 lines · Srikar Dronamraju

Move Macro W to asm/insn.h

Macro W used to know if the instructions are valid for user-space/kernel space. This macro is used by kprobes and user_bkpt. (i.e user space breakpoint assistance layer.) So moving it to a common header file asm/insn.h.

Hmm, I don't think this shortest macro name is good to expose commonly... And also, since we already have inat (instruction attribute) table, we'd better expand an inat bit to indicate which instruction can be probed/boosted.

Quoted 8 lines · Masami Hiramatsu

Quoted 6 lines · Srikar Dronamraju

Move Macro W to asm/insn.h

Macro W used to know if the instructions are valid for user-space/kernel space. This macro is used by kprobes and user_bkpt. (i.e user space breakpoint assistance layer.) So moving it to a common header file asm/insn.h.

Quoted 5 lines

Hmm, I don't think this shortest macro name is good to expose commonly... And also, since we already have inat (instruction attribute) table, we'd better expand an inat bit to indicate which instruction can be probed/boosted.

Guess we would need three bits,
- Instruction can be probed in kernel.

- Instruction can be probed in user space.
- Instruction can be boosted.

Or do you have other ideas?

--
Thanks and Regards
Srikar

User Space Breakpoint Assistance Layer (USER_BKPT)

...

+/*
+ * Read @nbytes at @vaddr from @tsk into @kbuf. Return number of bytes read.
+ * Not exported, but available for use by arch-specific user_bkpt code.
+ */

kernel/user_bkpt.c new file +7 -0

+
+ * Write @nbytes from @kbuf at @vaddr in @tsk.  Return number of bytes written.
+ * Can be used to write to stack or data VM areas, but not instructions.
+ * Not exported, but available for use by arch-specific user_bkpt code.
+ */
+int user_bkpt_write_data(struct task_struct *tsk, unsigned long vaddr,
+					const void *kbuf, int nbytes)

kernel/user_bkpt.c new file +36 -0

+{
+	pgd_t *pgd;
+	pud_t *pud;
+	pmd_t *pmd;
+	pte_t *pte;
+
+	pgd = pgd_offset(mm, vaddr);
+	pud = pud_alloc(mm, pgd, vaddr);
+	if (!pud)
+		return NULL;
+	pmd = pmd_alloc(mm, pud, vaddr);
+	if (!pmd)
+		return NULL;
+	pte = pte_alloc_map(mm, pmd, vaddr);
+	return pte;
+}
+
+static int write_opcode(struct task_struct *tsk, unsigned long vaddr,
+						user_bkpt_opcode_t opcode)
+{
+	struct mm_struct *mm;
+	struct vm_area_struct *vma;
+	struct page *old_page, *new_page;
+	void *maddr;
+	pte_t *old_pte;
+	int offset;
+	int ret = -EINVAL;
+
+	if (!tsk)
+		return ret;
+
+	mm = get_task_mm(tsk);
+	if (!mm)
+		return ret;
+
+	down_read(&mm->mmap_sem);

kernel/user_bkpt.c new file +10 -0

+	if (!new_page) {
+		ret = -ENOMEM;
+		goto unlock_out;
+	}
+
+	/*
+	 * check if the page we are interested is read-only mapped
+	 * Since we are interested in text pages, Our pages of interest
+	 * should be mapped read-only.
+	 */

kernel/user_bkpt.c new file +20 -0

+	old_pte = get_pte(mm, vaddr);
+	if (!old_pte) {
+		ret = -EINVAL;
+		goto unlock_out;
+	}
+
+	/*
+	 * Now replace the page in vma with the new page.
+	 * This is a text page; so, setup mapping and index.
+	 */
+	new_page->mapping = old_page->mapping;
+	new_page->index = old_page->index;
+	ret = replace_page(vma, old_page, new_page, *old_pte);
+
+unlock_out:
+	if (ret != 0)
+		page_cache_release(new_page);
+	put_page(old_page); /* we did a get_page in the beginning */
+	up_read(&mm->mmap_sem);
+mmput_out:

+ * Returns 0 if the vaddr is a valid instruction address.
+ * @tsk: the probed task
+ * @vaddr: virtual address of the instruction to be verified.
+ *
+ * Possible errors:
+ * -%EINVAL: Instruction passed is not a valid instruction address.
+ */

kernel/user_bkpt.c new file +10 -0

+int user_bkpt_validate_insn_addr(struct task_struct *tsk, unsigned long vaddr)
+{
+	int result;
+
+	result = check_vma(tsk, vaddr);
+	if (result != 0)
+		return result;
+	if (arch->validate_address)
+		result = arch->validate_address(tsk, vaddr);
+	return result;

kernel/user_bkpt.c new file +22 -0

+	if (uses_xol_strategy(user_bkpt->strategy)) {
+		BUG_ON(!user_bkpt->xol_vaddr);
+		return arch->pre_xol(tsk, user_bkpt, tskinfo, regs);
+	}
+
+	/*
+	 * Single-step this instruction inline.  Replace the breakpoint
+	 * with the original opcode.
+	 */
+	result = arch->set_orig_insn(tsk, user_bkpt, false);
+	if (result == 0)
+		arch->set_ip(regs, user_bkpt->vaddr);
+	return result;
+}
+
+/**
+ * user_bkpt_post_sstep - prepare to resume execution after single-step
+ * @tsk: the probed task
+ * @user_bkpt: the probepoint information, as with @user_bkpt_pre_sstep()
+ * @tskinfo: the @user_bkpt_task_arch_info object, if any, passed to
+ *	@user_bkpt_pre_sstep()
+ * @regs: reflects the saved state of @tsk after the single-step

kernel/user_bkpt.c new file +10 -0

+	if (uses_xol_strategy(user_bkpt->strategy))
+		return arch->post_xol(tsk, user_bkpt, tskinfo, regs);
+
+	/*
+	 * Single-stepped this instruction inline.  Put the breakpoint
+	 * instruction back.
+	 */
+	return arch->set_bkpt(tsk, user_bkpt);
+}
+
 
...

Quoted 3 lines · On Sat, 20 Mar 2010 19:55:41 +0530 Srikar Dronamraju…

...

Quoted 3 lines

+/**
+ * user_bkpt_validate_insn_addr - Validate if the instruction is an
+ * executable vma.

It used to be the case that the above linebreak is "wrong". (Nobody ever tests their kerneldoc output!) I have a vague feeling that this might have been fixed lately. Randy?

Quoted 3 lines

User Space Breakpoint Assistance Layer (USER_BKPT)

A quick scan, just to show I was paying attention ;)

kernel/user_bkpt.c line 101

Quoted 11 lines

kernel/user_bkpt.c new file +10 -0

+int user_bkpt_read_vm(struct task_struct *tsk, unsigned long vaddr,
+						void *kbuf, int nbytes)
+{
+	if (tsk == current) {
+		int nleft = copy_from_user(kbuf, (void __user *) vaddr,
+				nbytes);
+		return nbytes - nleft;
+	} else
+		return access_process_vm(tsk, vaddr, kbuf, nbytes, 0);
+}

copy_from_user() takes and returns an unsigned long arg but this function is converting these to and from ints. That's OK if we're 100% sure that we'll never get or return an arg >2G. Otherwise things could get ghastly. Please have a think. (Dittoes for some other functionss around here).

include/linux/uprobes.h new file +6 -0

+struct uprobe {
+       /*
+        * The pid of the probed process.  Currently, this can be the
+        * thread ID (task->pid) of any active thread in the process.
+        */
+       pid_t pid;

include/linux/sched.h +3 -0

index dad7f66..2d2433a 100644
@@ -1506,6 +1506,9 @@ struct task_struct {
                unsigned long memsw_bytes; /* uncharged mem+swap usage */
        } memcg_batch;
 #endif
+#ifdef CONFIG_UPROBES
+       struct uprobe_task *utask;
+#endif
 };
 
 /* Future-safe accessor for struct task_struct's cpus_allowed. */

include/linux/tracehook.h +14 -0

index 10db010..9a91d1e 100644
@@ -49,6 +49,7 @@
 #include <linux/sched.h>
 #include <linux/ptrace.h>
 #include <linux/security.h>
+#include <linux/uprobes.h>
 struct linux_binprm;
 
 /**

@@ -204,6 +205,11 @@ static inline void tracehook_report_exec(struct linux_binfmt *fmt,
        if (!ptrace_event(PT_TRACE_EXEC, PTRACE_EVENT_EXEC, 0) &&
            unlikely(task_ptrace(current) & PT_PTRACED))
                send_sig(SIGTRAP, current, 0);
+
+#ifdef CONFIG_UPROBES
+       if (unlikely(current->utask))
+               uprobe_free_utask();
+#endif
 }
 
 /**

@@ -219,6 +225,10 @@ static inline void tracehook_report_exec(struct linux_binfmt *fmt,
 static inline void tracehook_report_exit(long *exit_code)
 {
        ptrace_event(PT_TRACE_EXIT, PTRACE_EVENT_EXIT, *exit_code);
+#ifdef CONFIG_UPROBES
+       if (unlikely(current->utask))
+               uprobe_free_utask();
+#endif
 }
 
 /**

@@ -293,6 +303,10 @@ static inline void tracehook_report_clone(struct pt_regs *regs,
                sigaddset(&child->pending.signal, SIGSTOP);
                set_tsk_thread_flag(child, TIF_SIGPENDING);
        }
+#ifdef CONFIG_UPROBES
+       if (unlikely(current->utask))
+               uprobe_handle_clone(clone_flags, child);
+#endif
 }
 
 /**

Also, like we discussed in person,

Quoted 6 lines

include/linux/uprobes.h new file +6 -0

+struct uprobe {
+       /*
+        * The pid of the probed process.  Currently, this can be the
+        * thread ID (task->pid) of any active thread in the process.
+        */
+       pid_t pid;

include/linux/uprobes.h line 55

Quoted 10 lines

include/linux/uprobes.h new file +10 -0

+
+       /* Location of the probepoint */
+       unsigned long vaddr;
+
+       /* Handler to run when the probepoint is hit */
+       void (*handler)(struct uprobe*, struct pt_regs*);
+
+       /* true if handler runs in interrupt context*/
+       bool handler_in_interrupt;
+}; 

I would still prefer to see something like:

vma:offset, instead of tid:vaddr

You want to probe a symbol in a DSO, filtering per-task comes after that if desired.

Also, like we discussed in person, I think we can do away with the handler_in_interrupt thing by letting the handler have an error return value and doing something like:

do_int3:

  uprobe = find_probe_point(addr);

  pagefault_disable();
  err = uprobe->handler(uprobe, regs);
  pagefault_enable();

  if (err == -EFAULT) {
    /* set TIF flag and call the handler again from
       task context */
  }

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Everybody else simply places callbacks in kernel/fork.c and kernel/exit.c, but as it is I don't think you want per-task state like this.

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

Also, I would simply kill the user_bkpt stuff and merge it into uprobes, we don't have a kernel_bkpt thing either, only kprobes.

Hi Peter,

Quoted 22 lines · Srikar Dronamraju

Quoted 6 lines

include/linux/uprobes.h new file +6 -0

+struct uprobe {
+       /*
+        * The pid of the probed process.  Currently, this can be the
+        * thread ID (task->pid) of any active thread in the process.
+        */
+       pid_t pid;

include/linux/uprobes.h line 55

Quoted 10 lines

include/linux/uprobes.h new file +10 -0

+
+       /* Location of the probepoint */
+       unsigned long vaddr;
+
+       /* Handler to run when the probepoint is hit */
+       void (*handler)(struct uprobe*, struct pt_regs*);
+
+       /* true if handler runs in interrupt context*/
+       bool handler_in_interrupt;
+}; 

I would still prefer to see something like:

vma:offset, instead of tid:vaddr

Quoted 3 lines

You want to probe a symbol in a DSO, filtering per-task comes after that if desired.

do you mean the user should be specifying 357c200000:74b80 to denote 000000357c274b80? or /lib64/libc.so.6:74b80
And we trace all the process which have mapped this address?

Quoted 17 lines

Also, like we discussed in person, I think we can do away with the handler_in_interrupt thing by letting the handler have an error return value and doing something like:

do_int3:

  uprobe = find_probe_point(addr);

  pagefault_disable();
  err = uprobe->handler(uprobe, regs);
  pagefault_enable();

  if (err == -EFAULT) {
    /* set TIF flag and call the handler again from
       task context */
  }

Quoted 3 lines

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Okay but what if the handler is coded to sleep.

Quoted 4 lines

Everybody else simply places callbacks in kernel/fork.c and kernel/exit.c, but as it is I don't think you want per-task state like this.

Quoted 5 lines

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

where are the per task slots stored?
or Are you looking at a XOL vma area per DSO?

Quoted 3 lines

Also, I would simply kill the user_bkpt stuff and merge it into uprobes, we don't have a kernel_bkpt thing either, only kprobes.

We had uprobes as one single layer. However it was suggested that breaking it up into two layers was useful because it would help code reuse. Esp it was felt that a generic user_bkpt layer would be far more useful than being used for just uprobes.
Here are links where these discussion happened.

Quoted 24 lines · Srikar Dronamraju

Hi Peter,

Quoted 22 lines · Srikar Dronamraju

Quoted 6 lines

include/linux/uprobes.h new file +6 -0

+struct uprobe {
+       /*
+        * The pid of the probed process.  Currently, this can be the
+        * thread ID (task->pid) of any active thread in the process.
+        */
+       pid_t pid;

include/linux/uprobes.h line 55

Quoted 10 lines

include/linux/uprobes.h new file +10 -0

+
+       /* Location of the probepoint */
+       unsigned long vaddr;
+
+       /* Handler to run when the probepoint is hit */
+       void (*handler)(struct uprobe*, struct pt_regs*);
+
+       /* true if handler runs in interrupt context*/
+       bool handler_in_interrupt;
+}; 

I would still prefer to see something like:

vma:offset, instead of tid:vaddr

Quoted 7 lines

Quoted 3 lines

You want to probe a symbol in a DSO, filtering per-task comes after that if desired.

do you mean the user should be specifying 357c200000:74b80 to denote 000000357c274b80? or /lib64/libc.so.6:74b80
And we trace all the process which have mapped this address?

Well userspace would simply specify something like: /lib/libc.so:malloc, we'd probably communicate that to the kernel using a filedesc and offset.

And yes, all processes that share that DSO, consumers can install filters.

Quoted 21 lines

Quoted 20 lines

Also, like we discussed in person, I think we can do away with the handler_in_interrupt thing by letting the handler have an error return value and doing something like:

do_int3:

  uprobe = find_probe_point(addr);

  pagefault_disable();
  err = uprobe->handler(uprobe, regs);
  pagefault_enable();

  if (err == -EFAULT) {
    /* set TIF flag and call the handler again from
       task context */
  }

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Quoted 1 line

Okay but what if the handler is coded to sleep.

Don't do that ;-)

What reason would you have to sleep from a int3 anyway? You want to log bits and get on with life, right? The only interesting case is faulting when some memory references you want are not currently available, and that can be done as suggested.

Quoted 10 lines

Quoted 9 lines

Everybody else simply places callbacks in kernel/fork.c and kernel/exit.c, but as it is I don't think you want per-task state like this.

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

Quoted 2 lines

where are the per task slots stored?
or Are you looking at a XOL vma area per DSO?

The per task slot (note the singular, each task needs only ever have a single slot since a task can only ever hit one trap at a time) would live in the task TLS or task stack.

Quoted 9 lines

Quoted 3 lines

Also, I would simply kill the user_bkpt stuff and merge it into uprobes, we don't have a kernel_bkpt thing either, only kprobes.

We had uprobes as one single layer. However it was suggested that breaking it up into two layers was useful because it would help code reuse. Esp it was felt that a generic user_bkpt layer would be far more useful than being used for just uprobes.
Here are links where these discussion happened.

I'm so not going to read ancient emails on a funky list. What re-use? uprobe should be the only interface to this, there's no second interface to kprobes either is there?

Quoted 2 lines

And yes, all processes that share that DSO, consumers can install filters.

Hmm, for low-level interface, it will be good. If we provide a user interface(trace_uprobe.c), we'd better add pid filter for it.

Quoted 25 lines

Quoted 17 lines

Quoted 17 lines

Also, like we discussed in person, I think we can do away with the handler_in_interrupt thing by letting the handler have an error return value and doing something like:

do_int3:

  uprobe = find_probe_point(addr);

  pagefault_disable();
  err = uprobe->handler(uprobe, regs);
  pagefault_enable();

  if (err == -EFAULT) {
    /* set TIF flag and call the handler again from
       task context */
  }

Quoted 5 lines

Quoted 3 lines

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Okay but what if the handler is coded to sleep.

Don't do that ;-)

Quoted 4 lines

What reason would you have to sleep from a int3 anyway? You want to log bits and get on with life, right? The only interesting case is faulting when some memory references you want are not currently available, and that can be done as suggested.

Out of curiously, what does the task-context mean? ('current' is probed task in int3, isn't it?). I think, uprobe handler can cause page fault (and should sleep) if the page is swapped out.

Quoted 13 lines

Quoted 12 lines

Quoted 9 lines

Everybody else simply places callbacks in kernel/fork.c and kernel/exit.c, but as it is I don't think you want per-task state like this.

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

where are the per task slots stored?
or Are you looking at a XOL vma area per DSO?

Quoted 3 lines

The per task slot (note the singular, each task needs only ever have a single slot since a task can only ever hit one trap at a time) would live in the task TLS or task stack.

Hmm, I just worried about whether TLS/task stack can be executable (no one set NX bit).

Quoted 10 lines

Quoted 9 lines

Quoted 3 lines

Also, I would simply kill the user_bkpt stuff and merge it into uprobes, we don't have a kernel_bkpt thing either, only kprobes.

We had uprobes as one single layer. However it was suggested that breaking it up into two layers was useful because it would help code reuse. Esp it was felt that a generic user_bkpt layer would be far more useful than being used for just uprobes.
Here are links where these discussion happened.

Quoted 3 lines

I'm so not going to read ancient emails on a funky list. What re-use? uprobe should be the only interface to this, there's no second interface to kprobes either is there?

It will be good when we start working on 'ptrace2' :) Anyway, the patch order looks a bit odd, because user_bkpt uses XOL but XOL patch is introduced after user_bkpt patch...

Quoted 6 lines · Masami Hiramatsu

Quoted 2 lines

And yes, all processes that share that DSO, consumers can install filters.

Hmm, for low-level interface, it will be good. If we provide a user interface(trace_uprobe.c), we'd better add pid filter for it.

ftrace already has pid filters.

Quoted 26 lines

Quoted 26 lines

Quoted 18 lines

Quoted 18 lines

Also, like we discussed in person, I think we can do away with the handler_in_interrupt thing by letting the handler have an error return value and doing something like:

do_int3:

  uprobe = find_probe_point(addr);

  pagefault_disable();
  err = uprobe->handler(uprobe, regs);
  pagefault_enable();

  if (err == -EFAULT) {
    /* set TIF flag and call the handler again from
       task context */
  }

Quoted 5 lines

Quoted 3 lines

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Okay but what if the handler is coded to sleep.

Don't do that ;-)

Quoted 8 lines

Quoted 4 lines

What reason would you have to sleep from a int3 anyway? You want to log bits and get on with life, right? The only interesting case is faulting when some memory references you want are not currently available, and that can be done as suggested.

Out of curiously, what does the task-context mean? ('current' is probed task in int3, isn't it?). I think, uprobe handler can cause page fault (and should sleep) if the page is swapped out.

Task context means the regular kernel task stack where we can schedule, int3 has its own exception stack and we cannot schedule from that.

And yes, the fault thing is the one case where sleeping makes sense and is dealt with in my proposal, you don't need two handlers for that, just call it from trap context with pagefault_disable() and when it fails with -EFAULT set a TIF flag to deal with it later when we're back in task context.

There is a very good probability that the memory you want to reference is mapped (because typically the program itself will want to access it as well) so doing the optimistic access with pagefault_disabled() will work most of the times and you only end up taking the slow path when it does indeed fault.

Quoted 13 lines

Quoted 13 lines

Quoted 12 lines

Quoted 9 lines

Everybody else simply places callbacks in kernel/fork.c and kernel/exit.c, but as it is I don't think you want per-task state like this.

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

where are the per task slots stored?
or Are you looking at a XOL vma area per DSO?

Quoted 6 lines

Quoted 3 lines

The per task slot (note the singular, each task needs only ever have a single slot since a task can only ever hit one trap at a time) would live in the task TLS or task stack.

Hmm, I just worried about whether TLS/task stack can be executable (no one set NX bit).

You can remove the NX bit from that one page I guess.

Quoted 14 lines

Quoted 13 lines

Quoted 9 lines

Quoted 3 lines

Also, I would simply kill the user_bkpt stuff and merge it into uprobes, we don't have a kernel_bkpt thing either, only kprobes.

We had uprobes as one single layer. However it was suggested that breaking it up into two layers was useful because it would help code reuse. Esp it was felt that a generic user_bkpt layer would be far more useful than being used for just uprobes.
Here are links where these discussion happened.

I'm so not going to read ancient emails on a funky list. What re-use? uprobe should be the only interface to this, there's no second interface to kprobes either is there?

Quoted 3 lines

It will be good when we start working on 'ptrace2' :) Anyway, the patch order looks a bit odd, because user_bkpt uses XOL but XOL patch is introduced after user_bkpt patch...

But why would ptrace2 use a different interface? Also, why introduce some abstraction layer now without having a user for it, you could always restructure things and or add interfaces later when you have a clear idea what it is you need.

Anyway, the patch order looks a bit odd, because user_bkpt uses XOL but XOL patch is introduced after user_bkpt patch...

Thank you,

Signature · 2 lines

Masami Hiramatsu
e-mail: [email protected]

Quoted 11 lines · Srikar Dronamraju

Quoted 7 lines

I would still prefer to see something like:

vma:offset, instead of tid:vaddr

You want to probe a symbol in a DSO, filtering per-task comes after that if desired.

do you mean the user should be specifying 357c200000:74b80 to denote 000000357c274b80? or /lib64/libc.so.6:74b80
And we trace all the process which have mapped this address?

Well userspace would simply specify something like: /lib/libc.so:malloc, we'd probably communicate that to the kernel using a filedesc and offset.

And yes, all processes that share that DSO, consumers can install filters.

Quoted 21 lines

Quoted 20 lines

Also, like we discussed in person, I think we can do away with the handler_in_interrupt thing by letting the handler have an error return value and doing something like:

do_int3:

  uprobe = find_probe_point(addr);

  pagefault_disable();
  err = uprobe->handler(uprobe, regs);
  pagefault_enable();

  if (err == -EFAULT) {
    /* set TIF flag and call the handler again from
       task context */
  }

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Quoted 1 line

Okay but what if the handler is coded to sleep.

Don't do that ;-)

What reason would you have to sleep from a int3 anyway? You want to log bits and get on with life, right? The only interesting case is faulting when some memory references you want are not currently available, and that can be done as suggested.

Now the question is, where the complexity needs to be.

Quoted 1 line

Now the question is, where the complexity needs to be.

Both in-tree consumers of uprobes (ftrace and perf) are capable of task filters. [...]

Quoted 1 line · Ananth N Mavinakayanahalli

Now the question is, where the complexity needs to be.

Both in-tree consumers of uprobes (ftrace and perf) are capable of task filters.

But the thing is, dso:sym is very much not a task property, adding task filters afterwards sure makes sense in some cases but it should not be the primary mode.

If people really want to optimize this we can easily add a few bits of task state which could tell the trap handler to not even bother looking up things but restart as fast as possible.

Quoted 11 lines

Quoted 7 lines

I would still prefer to see something like:

vma:offset, instead of tid:vaddr

You want to probe a symbol in a DSO, filtering per-task comes after that if desired.

do you mean the user should be specifying 357c200000:74b80 to denote 000000357c274b80? or /lib64/libc.so.6:74b80
And we trace all the process which have mapped this address?

Well userspace would simply specify something like: /lib/libc.so:malloc, we'd probably communicate that to the kernel using a filedesc and offset.

And yes, all processes that share that DSO, consumers can install filters.

Quoted 5 lines

Quoted 4 lines

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Quoted 1 line

Okay but what if the handler is coded to sleep.

Don't do that ;-)

What reason would you have to sleep from a int3 anyway? You want to log bits and get on with life, right? The only interesting case is faulting when some memory references you want are not currently available, and that can be done as suggested.

Quoted 10 lines

Quoted 9 lines

Everybody else simply places callbacks in kernel/fork.c and kernel/exit.c, but as it is I don't think you want per-task state like this.

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

Quoted 2 lines

where are the per task slots stored?
or Are you looking at a XOL vma area per DSO?

The per task slot (note the singular, each task needs only ever have a single slot since a task can only ever hit one trap at a time) would live in the task TLS or task stack.

Hi Peter,

Quoted 12 lines

Quoted 11 lines

Quoted 7 lines

I would still prefer to see something like:

vma:offset, instead of tid:vaddr

You want to probe a symbol in a DSO, filtering per-task comes after that if desired.

do you mean the user should be specifying 357c200000:74b80 to denote 000000357c274b80? or /lib64/libc.so.6:74b80
And we trace all the process which have mapped this address?

Quoted 7 lines

Well userspace would simply specify something like: /lib/libc.so:malloc, we'd probably communicate that to the kernel using a filedesc and offset.

And yes, all processes that share that DSO, consumers can install filters.

I think perf would be using uprobes in one of the four ways.
- Trace a particular process.
- Trace a particular session.
- Trace all instances of an executable.
- Trace all programs in the system.

If we use global approach, filtering would still be part of the handler. So even if we want to probe just one process, we would still take hit for all processes that map the DSO and hit that vaddr.
Other process could be hitting the probepoint more often while the probed process could rarely be hitting the probepoint. This could place significant overhead on the system.

Also with KSM, the page we are probing could be part of the stable tree and mapped by different virtual machines. Can this lead to interruptting work on an unrelated virtual machine? If yes, Is it okay to interrupt an unrelated VM? If not, what measures need to be taken?

Currently perf can be used by priviledged users. However when perf gets to trace user space programs, would it still be limited to priviledged users. Do we have plans to allow users to trace their owned applications thro perf?

Quoted 4 lines

Quoted 4 lines

Quoted 3 lines

This should allow the handler to optimistically access memory from the trap handler, but in case it does need to fault pages in we'll call it from task context.

Quoted 9 lines

Quoted 1 line

Okay but what if the handler is coded to sleep.

Don't do that ;-)

What reason would you have to sleep from a int3 anyway? You want to log bits and get on with life, right? The only interesting case is faulting when some memory references you want are not currently available, and that can be done as suggested.

Though one of the usp of uprobes is non disruptive tracing, applications like debuggers who do disruptive tracing can benefit from uprobes.

Debuggers could use uprobes as a feature to implement inserting/removing breakpoints and get the out of line single-stepping. In an earlier discussion http://lkml.org/lkml/2010/1/26/344 Tom Tromey did say that if a facility was given, it could be used in gdb.

What I expect is the tracee to inform the tracer that it has hit the breakpoint and "wait" for the tracer to give indication to continue.

Benefits could be
- Debuggers can benefit from execution out of line and can debug multithread processes much better.

- Two debbugers/tracers could trace the same process. One of the tracer could be strace, while the other one could be gdb.

- perf and debugger could be interested in the same vaddr for that process and still continue to work.
Lets say debugger and perf are interested in a particular function for example malloc.
If perf uses uprobes and debuggers uses existing methods, then perf measures of malloc may not be accurate as it misses those mallocs of the process that's being debugged. However I agree that its a very very very minute case.

Quoted 10 lines

Quoted 10 lines

Quoted 9 lines

Everybody else simply places callbacks in kernel/fork.c and kernel/exit.c, but as it is I don't think you want per-task state like this.

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

Quoted 7 lines

Quoted 2 lines

where are the per task slots stored?
or Are you looking at a XOL vma area per DSO?

The per task slot (note the singular, each task needs only ever have a single slot since a task can only ever hit one trap at a time) would live in the task TLS or task stack.

Do we need a buy-in from glibc folks to do this?
Also here is what Roland had once said about TLS.

"Next we come to the problem of where to store copied instructions for stepping. The idea of stealing a stack page for this is a non-starter. For both security and robustness, it's never acceptable to introduce a user mapping that is both writable and executable, even temporarily. We need to use an otherwise unused page in the address space, that will be read/execute only for the user, we can write to it only from kernel mode."

Quoted 18 lines

Quoted 7 lines

Quoted 7 lines

Quoted 6 lines

One thing I would like to see is a slot per task, that has a number of advantages over the current patch-set in that it doesn't have one page limit in number of probe sites, nor do you need to insert vmas into each and every address space that happens to have your DSO mapped.

Quoted 7 lines

Quoted 2 lines

where are the per task slots stored?
or Are you looking at a XOL vma area per DSO?

The per task slot (note the singular, each task needs only ever have a single slot since a task can only ever hit one trap at a time) would live in the task TLS or task stack.

Do we need a buy-in from glibc folks to do this?
Also here is what Roland had once said about TLS.

Quoted 7 lines

"Next we come to the problem of where to store copied instructions for stepping. The idea of stealing a stack page for this is a non-starter. For both security and robustness, it's never acceptable to introduce a user mapping that is both writable and executable, even temporarily. We need to use an otherwise unused page in the address space, that will be read/execute only for the user, we can write to it only from kernel mode."

Before NX there simply was no option, anyway, I guess the writable requirement comes from being stack, and I'm not sure how TLS is done, but I guess that has similar constraints on being writable, right?

I've heard from people that some other OS does indeed have the trampoline in TLS.

I'm not sure, currently all the tracing bits require root. One of the complications is that dynamic trace events (kprobes and uprobes) share a global namespace, so making that accessible to users might be interesting.

So one thing we can do to avoid some of the trap overhead is to de-couple the trace event creation from trace event enable (pretty much already so for existing implementations), so while you define a dynamic trace event as dso:sym, you provide ways to enable it globally and per task.

We'd basically need a global and per-task refcount on enable and make sure the breakpoint is installed properly for (global || task).

That way a perf per-cpu event will do the global enable, and a perf per-task event will do the task enable.

A double scribble will be an issue for the current generation of debuggers anyway, right?

But yes, I suppose if you want to use uprobes for debuggers then yes it makes sense to allow to put the task to sleep. One way would be to provide means for the handler to detect the context and simply always return -EFAULT from the trap context.

Uprobes documentation.

Signed-off-by Jim Keniston <[email protected]>

Signed-off-by Srikar Dronamraju <[email protected]>

---

 Documentation/uprobes.txt |  244 +++++++++++++++++++++++++++++++++++++++++++++
 1 files changed, 244 insertions(+), 0 deletions(-)
 create mode 100644 Documentation/uprobes.txt

Documentation/uprobes.txt new file +40 -0

new file mode 100644
index 0000000..08bbf24
@@ -0,0 +1,244 @@
+Title	: User-Space Probes (Uprobes)
+Authors	: Jim Keniston <[email protected]>
+	: Srikar Dronamraju <[email protected]>
+
+CONTENTS
+
+1. Concepts: Uprobes
+2. Architectures Supported
+3. Configuring Uprobes
+4. API Reference
+5. Uprobes Features and Limitations
+6. Probe Overhead
+7. TODO
+8. Uprobes Team
+9. Uprobes Example
+
+1. Concepts: Uprobes
+
+Uprobes enables you to dynamically break into any routine in a
+user application and collect debugging and performance information
+non-disruptively. You can trap at any code address, specifying a
+kernel handler routine to be invoked when the breakpoint is hit.
+
+A uprobe can be inserted on any instruction in the application's
+virtual address space.  The registration function register_uprobe()
+specifies which process is to be probed, where the probe is to be
+inserted, and what handler is to be called when the probe is hit.
+
+Uprobes-based instrumentation can be packaged as a kernel
+module.  In the simplest case, the module's init function installs
+("registers") one or more probes, and the exit function unregisters
+them.
+
+1.1 How Does a Uprobe Work?
+
+When a uprobe is registered, Uprobes makes a copy of the probed
+instruction, stops the probed application, replaces the first byte(s)
+of the probed instruction with a breakpoint instruction (e.g., int3
+on i386 and x86_64), and allows the probed application to continue.
+(When inserting the breakpoint, Uprobes uses background page

Documentation/uprobes.txt new file +26 -0

+When run in task context, the handler may block, but keep in mind that
+the probed thread remains stopped while your handler runs.
+
+Next, Uprobes single-steps its copy of the probed instruction and
+resumes execution of the probed process at the instruction following
+the probepoint.  (It would be simpler to single-step the actual
+instruction in place, but then Uprobes would have to temporarily
+remove the breakpoint instruction.  This would create problems in a
+multithreaded application.  For example, it would open a time window
+when another thread could sail right past the probepoint.)
+
+Instruction copies to be single-stepped are stored in a per-process
+"execution out of line (XOL) area," which is a little VM area
+created by Uprobes in each probed process's address space.
+
+Uprobes handles interesting events in the lifetime of the probed
+process, such as fork, clone, exec, and exit.
+
+1.2 Multithreaded Applications
+
+Uprobes supports the probing of multithreaded applications.  Uprobes
+imposes no limit on the number of threads in a probed application.
+All threads in a process use the same text pages, so every probe
+in a process affects all threads; of course, each thread hits the
+probepoint (and runs the handler) independently.  Multiple threads
+may run the same handler simultaneously.  If you want a particular

Documentation/uprobes.txt new file +73 -0

+architectures:
+
+- x86
+
+3. Configuring Uprobes
+
+When configuring the kernel using make menuconfig/xconfig/oldconfig,
+ensure that CONFIG_UPROBES is set to "y". Under "General setup" select
+"User-space breakpoint assistance" then select "User-space probes".
+
+So that you can load and unload Uprobes-based instrumentation modules,
+make sure "Loadable module support" (CONFIG_MODULES) and "Module
+unloading" (CONFIG_MODULE_UNLOAD) are set to "y".
+
+4. API Reference
+
+The Uprobes API includes a "register" function and an "unregister"
+function for uprobes.  Here are terse, mini-man-page specifications for
+these functions and the associated probe handlers that you'll write.
+See the latter half of this document for examples.
+
+4.1 register_uprobe
+
+#include <linux/uprobes.h>
+int register_uprobe(struct uprobe *u);
+
+Sets a breakpoint at virtual address u->vaddr in the process whose
+pid is u->pid.  When the breakpoint is hit, Uprobes calls u->handler.
+If u->handler_in_interrupt is set, the handler runs in interrupt
+context. Otherwise it runs in task context.
+
+register_uprobe() returns 0 on success, or a negative errno
+otherwise.
+
+User's handler (u->handler):
+#include <linux/uprobes.h>
+#include <linux/ptrace.h>
+void handler(struct uprobe *u, struct pt_regs *regs);
+
+Called with u pointing to the uprobe associated with the breakpoint,
+and regs pointing to the struct containing the registers saved when
+the breakpoint was hit.
+
+4.2 unregister_uprobe
+
+#include <linux/uprobes.h>
+void unregister_uprobe(struct uprobe *u);
+
+Removes the specified probe.  The unregister function can be called
+at any time after the probe has been registered, and can be called
+from a uprobe handler.
+
+5. Uprobes Features and Limitations
+
+The user is expected to assign values to the following members
+of struct uprobe: pid, vaddr, handler, and handler_in_interrupt.
+Uprobes may produce unexpected results if you:
+- change the contents of a uprobe object while it is registered; or
+- attempt to register a uprobe that is already registered.
+
+In this implementation, Uprobes allows only one uprobe at a particular
+address.
+
+Any number of kernel modules may probe a particular process
+simultaneously, and a particular module may probe any number of
+processes simultaneously.
+
+Probes are shared by all threads in a process (including newly
+created threads).
+
+If a probed process exits or execs, Uprobes automatically
+unregisters all uprobes associated with that process.  Subsequent
+attempts to unregister these probes will be treated as no-ops.

Documentation/uprobes.txt new file +18 -0

+Some architectures may refuse to insert probes on other types of
+instructions.
+
+If you install a probe in an inline-able function, Uprobes makes
+no attempt to chase down all inline instances of the function and
+install probes there.  gcc may inline a function without being asked,
+so keep this in mind if you're not seeing the probe hits you expect.
+
+A probe handler can modify the environment of the probed function
+-- e.g., by modifying data structures, or by modifying the
+contents of the pt_regs struct (which are restored to the registers
+upon return from the breakpoint).  So Uprobes can be used, for example,
+to install a bug fix or to inject faults for testing.  Uprobes, of
+course, has no way to distinguish the deliberately injected faults
+from the accidental ones.  Don't drink and probe.
+
+When Uprobes establishes a probepoint on a previous unprobed page
+of text, Linux creates a new copy of the page via its copy-on-write

Documentation/uprobes.txt new file +47 -1

+iterations.
+
+Here are sample overhead figures (in usec) for x86 architecture.
+
+i686: Intel(R) Xeon(TM) CPU 2.40GHz
+Without probe module.
+100000 interations in 0.000650 sec i.e 0.006500 usec per iteration
+
+With probes and handler run in interrupt context.
+100000 interations in 0.340774 sec i.e 3.407740 usec per iteration
+probe overhead is  3.401240 usec per probe hit.
+
+With probes and handler run in task context.
+100000 interations in 0.365589 sec i.e 3.655890 usec per iteration
+probe overhead is 3.649390 usec per probe hit.
+
+x86_64: Intel(R) Xeon(R) CPU           X7350  @ 2.93GHz
+Without probe module.
+100000 interations in 0.000468 sec i.e  0.004680 usec per iteration
+
+With probes and handler run in interrupt context.
+100000 interations in 0.120369 sec i.e 1.203690 usec per iteration
+Probe overhead is 1.199010 usec per probe hit.
+
+With probes and handler run in task context.
+100000 interations in 0.130685 sec i.e 1.306850 usec per iteration
+Probe overhead is 1.302170 usec per probe hit.
+
+7. TODO
+
+a. Support for other architectures.
+b. Support for multiple probes at the same address.
+c. Support for boosted probes.
+d. Support return probes.
+
+8. Uprobes Team
+
+The following people have made major contributions to Uprobes:
+Jim Keniston - [email protected]
+Srikar Dronamraju - [email protected]
+Ananth Mavinakayanahalli - [email protected]
+Prasanna Panchamukhi - [email protected]
+Dave Wilder - [email protected]
+
+9. Uprobes Example
+
+samples/uprobes/uprobe_example.c
--

Review

Quoted 2 lines

(quoted diff) +2 -0

+
+This user-bkpt based version of Uprobes is implemented on the following

s/bkpt/breakpoint/

Thanks for the review,
The next version of the patchset will address your comments.

Quoted 5 lines

Review

Quoted 2 lines

(quoted diff) +2 -0

+
+This user-bkpt based version of Uprobes is implemented on the following

s/bkpt/breakpoint/

Your comment however made me realize that I had used user-bkpt here rather than user_bkpt.

user_bkpt is a layer that provides breakpoint insertion and removal. I wanted to mention that uprobes depends on user_bkpt layer. I think "This user_bkpt based version" is probably better than "This user-breakpoint based version"

This patchset implements Uprobes which enables you to dynamically break into any routine in a user space application and collect information non-disruptively.

Quoted 4 lines

This patchset implements Uprobes which enables you to dynamically break into any routine in a user space application and collect information non-disruptively.

What's missing here is a description of why all this is useful. Presumably much of the functionality which this feature offers can be done wholly in userspace. So I think it would be useful if you were to carefully explain the thinking here - what the value is, how people will use it, why it needs to be done in-kernel, etc. Right now if I was asked "why did you merge that", I'd say "gee, I dunno". I say that a lot. Knowing all of this would perhaps help me to understand your thinking regarding ftrace integration.

The code itself is positioned as non-x86-specific, but the implementation is x86-only. It would be nice to get some confirmation that other architectures can successfully use the core code. But that will be hard to arrange, so probably crossing our fingers is the best approach here.

The code scares me a bit from the "how can malicious people exploit it" point of view. Breaking into other users programs/memory, causing the kernel to scribble on itself, causing unbound memory consumption, etc. No specific issues that I can point at, just vague fear.

Do we know that exiting userspace will never ever already be using int3?

What happens if I run this code in 2016 on a CPU which has new opcodes which this code didn't know about?

When uprobes was being pushed five-odd years ago, it did all sorts of hair-raising things to avoid COWing shared pages. Lots of reasons were given why it *had* to avoid COW. But now it COWs. What were those reasons why COW was unacceptable, and what changed?