From: Yonghong Song <hidden> Date: 2017-11-13 22:11:44
Uprobe is a tracing mechanism for userspace programs.
Typical uprobe will incur overhead of two traps.
First trap is caused by replaced trap insn, and
the second trap is to execute the original displaced
insn in user space.
To reduce the overhead, kernel provides hooks
for architectures to emulate the original insn
and skip the second trap. In x86, emulation
is done for certain branch insns.
This patch extends the emulation to "push <reg>"
insns. These insns are typical in the beginning
of the function. For example, bcc
in https://github.com/iovisor/bcc repo provides
tools to measure funclantency, detect memleak, etc.
The tools will place uprobes in the beginning of
function and possibly uretprobes at the end of function.
This patch is able to reduce the trap overhead for
uprobe from 2 to 1.
Without this patch, uretprobe will typically incur
three traps. With this patch, if the function starts
with "push" insn, the number of traps can be
reduced from 3 to 2.
An experiment was conducted on two local VMs,
fedora 26 64-bit VM and 32-bit VM, both 4 processors
and 4GB memory, booted with latest tip repo (and this patch).
The host is MacBook with intel i7 processor.
The test program looks like
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <sys/time.h>
static void test() __attribute__((noinline));
void test() {}
int main() {
struct timeval start, end;
gettimeofday(&start, NULL);
for (int i = 0; i < 1000000; i++) {
test();
}
gettimeofday(&end, NULL);
printf("%ld\n", ((end.tv_sec * 1000000 + end.tv_usec)
- (start.tv_sec * 1000000 + start.tv_usec)));
return 0;
}
The program is compiled without optimization, and
the first insn for function "test" is "push %rbp".
The host is relatively idle.
Before the test run, the uprobe is inserted as below for uprobe:
echo 'p <binary>:<test_func_offset>' > /sys/kernel/debug/tracing/uprobe_events
echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
and for uretprobe:
echo 'r <binary>:<test_func_offset>' > /sys/kernel/debug/tracing/uprobe_events
echo 1 > /sys/kernel/debug/tracing/events/uprobes/enable
Unit: microsecond(usec) per loop iteration
x86_64 W/ this patch W/O this patch
uprobe 1.55 3.1
uretprobe 2.0 3.6
x86_32 W/ this patch W/O this patch
uprobe 1.41 3.5
uretprobe 1.75 4.0
You can see that this patch significantly reduced the overhead,
50% for uprobe and 44% for uretprobe on x86_64, and even more
on x86_32.
Signed-off-by: Yonghong Song <redacted>
---
arch/x86/include/asm/uprobes.h | 4 ++
arch/x86/kernel/uprobes.c | 111 +++++++++++++++++++++++++++++++++++++++--
2 files changed, 111 insertions(+), 4 deletions(-)
Changelogs:
v2 -> v3:
. Do not emulate 32bit application on x86_64 platforms
v1 -> v2:
. Address Oleg's comments
No, this doesn't look right, see my previous email. You should do this
check in the "if (insn->length == 2)" branch below, "push bp" should be
emulated correctly.
And test_thread_flag(TIF_ADDR32) is not right too. The caller is not
necessarily the probed task. See is_64bit_mm(mm) in arch_uprobe_analyze_insn().
And again... please check if uprobe_init_insn() fails or not in this case
(32bit task does, say, "push r8"). If it fails, your V2 should be fine.
To remind, uprobes && 32-bit is broken, let me quote my another email:
The 3rd bug means that you simply can't uprobe a 32bit task on a 64bit
system, the in_compat_syscall() logic in get_unmapped_area() looks very
wrong although I need to re-check.
I didn't have time for this problem so far. But emulation should work, so
you can hopefully test your patch.
Oleg.
+#ifdef CONFIG_X86_64
+ if (test_thread_flag(TIF_ADDR32))
+ return -ENOSYS;
+#endif
No, this doesn't look right, see my previous email. You should do this
check in the "if (insn->length == 2)" branch below, "push bp" should be
emulated correctly.
And test_thread_flag(TIF_ADDR32) is not right too. The caller is not
necessarily the probed task. See is_64bit_mm(mm) in arch_uprobe_analyze_insn().
And again... please check if uprobe_init_insn() fails or not in this case
(32bit task does, say, "push r8"). If it fails, your V2 should be fine.
To remind, uprobes && 32-bit is broken, let me quote my another email:
The 3rd bug means that you simply can't uprobe a 32bit task on a 64bit
system, the in_compat_syscall() logic in get_unmapped_area() looks very
wrong although I need to re-check.
Yes,
I didn't have time for this problem so far. But emulation should work, so
you can hopefully test your patch.
Ah, no, sizeof_long() is broken by the same reason, so you can't test it...
OK, I'll try to do something tomorrow, then we will see what can we do
with your patch...
But it would be nice if you can check what uprobe_init_insn() does in this
case, see above.
Oleg.
No, this doesn't look right, see my previous email. You should do this
check in the "if (insn->length == 2)" branch below, "push bp" should be
emulated correctly.
And test_thread_flag(TIF_ADDR32) is not right too. The caller is not
necessarily the probed task. See is_64bit_mm(mm) in arch_uprobe_analyze_insn().
I printed out some statistics. On x86_64 platform, for 32bit
application, test_thread_flag(TIF_ADDR32) returns true and
is_64bit_mm(mm) returns false. For 64bit application,
test_thread_flag(TIF_ADDR32) returns false and is_64bit_mm(mm) return
true. So that is why my patch works fine.
I did not fully understand how to trigger "the caller is not necessarily
the probed task." So in the next revision, I will use is_64bit_mm(mm)
instead.
And again... please check if uprobe_init_insn() fails or not in this case
(32bit task does, say, "push r8"). If it fails, your V2 should be fine.
The compiler won't generated "push r8" for 32bit task since register
"r8" is not available on 32bit instruction.
To remind, uprobes && 32-bit is broken, let me quote my another email:
The 3rd bug means that you simply can't uprobe a 32bit task on a 64bit
system, the in_compat_syscall() logic in get_unmapped_area() looks very
wrong although I need to re-check.
I didn't have time for this problem so far. But emulation should work, so
you can hopefully test your patch.
Oleg.
From: Yonghong Song <hidden> Date: 2017-11-14 22:44:19
On 11/14/17 8:03 AM, Oleg Nesterov wrote:
On 11/14, Oleg Nesterov wrote:
quoted
quoted
+#ifdef CONFIG_X86_64
+ if (test_thread_flag(TIF_ADDR32))
+ return -ENOSYS;
+#endif
No, this doesn't look right, see my previous email. You should do this
check in the "if (insn->length == 2)" branch below, "push bp" should be
emulated correctly.
And test_thread_flag(TIF_ADDR32) is not right too. The caller is not
necessarily the probed task. See is_64bit_mm(mm) in arch_uprobe_analyze_insn().
And again... please check if uprobe_init_insn() fails or not in this case
(32bit task does, say, "push r8"). If it fails, your V2 should be fine.
To remind, uprobes && 32-bit is broken, let me quote my another email:
The 3rd bug means that you simply can't uprobe a 32bit task on a 64bit
system, the in_compat_syscall() logic in get_unmapped_area() looks very
wrong although I need to re-check.
Yes,
quoted
I didn't have time for this problem so far. But emulation should work, so
you can hopefully test your patch.
Ah, no, sizeof_long() is broken by the same reason, so you can't test it...
Right. I hacked the emulate_push_stack (original name: push_ret_address)
with sizeof_long = 4, and 32bit binary uprobe works fine on x86_64
platform then... But that will involve a bigger change to propogate
the is_64bit_mm() along the call graph.
OK, I'll try to do something tomorrow, then we will see what can we do
with your patch...
Thanks for reviewing! I will wait for your further comments/direction
before next step.
But it would be nice if you can check what uprobe_init_insn() does in this
case, see above.
As mentioned in my previous email, for 32bit application,
compiler won't generate "push %r8" as "%r8" is only available on
x86_64 platform. For 32bit app, I see "push %bp" etc which does not
have rex_prefix. They cannot be emulated right now due to
emulate_push_stack needs change.
And test_thread_flag(TIF_ADDR32) is not right too. The caller is not
necessarily the probed task. See is_64bit_mm(mm) in arch_uprobe_analyze_insn().
I printed out some statistics. On x86_64 platform, for 32bit application,
test_thread_flag(TIF_ADDR32) returns true
See above. The caller can be 64-bit even if the probed task is 32bit. Or
vice versa.
and is_64bit_mm(mm) returns false.
This is what we need. Again, see its usage in arch_uprobe_analyze_insn()
and note that mm != current->mm.
So that is why my patch works fine.
test_thread_flag() can't work in general, see above.
I did not fully understand how to trigger "the caller is not necessarily the
probed task." So in the next revision, I will use is_64bit_mm(mm) instead.
register_for_each_vma() paths can call arch_uprobe_analyze_insn(), the task
which calls register_ has is not necessarily the task(s) we want to probe.
quoted
And again... please check if uprobe_init_insn() fails or not in this case
(32bit task does, say, "push r8"). If it fails, your V2 should be fine.
The compiler won't generated "push r8" for 32bit task since register "r8" is
not available on 32bit instruction.
And?
uprobes should be transparent even when it comes to user-space bugs. If
a 32bit app does asm(".byte 0x41, 0x50") for any reason we should either
deny to probe this insn (uprobe_init_insn() should fail), or we should
execute it out-of-line so that it will be trapped correctly.
Oleg.
Ah, no, sizeof_long() is broken by the same reason, so you can't test it...
Right. I hacked the emulate_push_stack (original name: push_ret_address)
with sizeof_long = 4, and 32bit binary uprobe works fine on x86_64 platform
then...
OK,
quoted
OK, I'll try to do something tomorrow, then we will see what can we do
with your patch...
Thanks for reviewing! I will wait for your further comments/direction
before next step.
Oh. tomorrow, I promise. Sorry I was bit busy today...
quoted
But it would be nice if you can check what uprobe_init_insn() does in this
case, see above.
As mentioned in my previous email, for 32bit application,
compiler won't generate "push %r8" as "%r8" is only available on
x86_64 platform.
But this is irrelevant, see my previous email.
So please, check if uprobe_init_insn() fails or not in this case. After that
we will know whether your patch needs the additional is_64bit_mm() check in
push_setup_xol_ops() or not.
Oleg.
So please, check if uprobe_init_insn() fails or not in this case. After that
we will know whether your patch needs the additional is_64bit_mm() check in
push_setup_xol_ops() or not.
OK, I did the check for you.
uprobe_init_insn() doesn't fail but insn_init(x86_64 => 0) parse it as
single-byte insn with OPCODE1 == 0x41, so push_setup_xol_ops() doesn't
need to worry about compat tasks.
In short, your "V2" should be fine except you can factor out
auprobe->push.ilen initialization (as you did in V3). Please send V4.
Oleg.
From: Yonghong Song <hidden> Date: 2017-11-15 17:26:05
On 11/15/17 9:07 AM, Oleg Nesterov wrote:
On 11/15, Oleg Nesterov wrote:
quoted
So please, check if uprobe_init_insn() fails or not in this case. After that
we will know whether your patch needs the additional is_64bit_mm() check in
push_setup_xol_ops() or not.
OK, I did the check for you.
uprobe_init_insn() doesn't fail but insn_init(x86_64 => 0) parse it as
single-byte insn with OPCODE1 == 0x41, so push_setup_xol_ops() doesn't
need to worry about compat tasks.
In short, your "V2" should be fine except you can factor out
auprobe->push.ilen initialization (as you did in V3). Please send V4.
Thanks a lot! I am just about to use inline asm or binary rewriter to
create such a code for testing...
I will send V4 shortly.