Ptrace,Utrace,Uprobes:Lightweight,DynamicTracingofUserApps

Ptrace

2星需积分: 34 65 浏览量 2010-08-27 15:36:13 上传评论收藏 172KB PDF 举报

资源推荐

资源详情

资源评论

Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User Apps

Jim Keniston

IBM

jkenisto@us.ibm.com

Ananth Mavinakayanahalli

IBM

ananth@in.ibm.com

Prasanna Panchamukhi

IBM

prasanna@in.ibm.com

Vara Prasad

IBM

varap@us.ibm.com

Abstract

The ptrace system-call API, though useful for many

tools such as gdb and strace, generally proves unsat-

isfactory when tracing multithreaded or multi-process

applications, especially in timing-dependent debugging

scenarios. With the utrace kernel API, a kernel-side

instrumentation module can track interesting events in

traced processes. The uprobes kernel API exploits

and extends utrace to provide kprobes-like, breakpoint-

based probing of user applications.

We describe how utrace, uprobes, and kprobes together

provide an instrumentation facility that overcomes some

limitations of ptrace. For attendees, familiarity with a

tracing API such as ptrace or kprobes will be helpful

but not essential.

1 Introduction

For a long time now, debugging user-space applications

has been dependent on the ptrace system call. Though

ptrace has been very useful and will almost certainly

continue to prove its worth, some of the requirements it

imposes on its clients are considered limiting. One im-

portant limitation is performance, which is inﬂuenced

by the high context-switch overheads inherent in the

ptrace approach.

The utrace patchset [3] mitigates this to a large extent.

Utrace provides in-kernel callbacks for the same sorts

of events reported by ptrace. The utrace patchset re-

implements ptrace as a client of utrace.

Uprobes is another utrace client. Analogous to kprobes

for the Linux



kernel, uprobes provides a simple, easy-

to-use API to dynamically instrument user applications.

Details of the design and implementation of uprobes

form the major portion of this paper.

We start by discussing the current situation in the user-

space tracing world. Sections 2 and 3 discuss the var-

ious instrumentation approaches possible and/or avail-

able. Section 4 goes on to discuss the goals that led

to the current uprobes design, while Section 5 details

the implementation. In the later sections, we put forth

some of the challenges, especially with regard to mod-

ifying text and handling of multithreaded applications.

Further, there is a brief discussion on how and where

we envision this infrastructure can be put to use. We ﬁ-

nally conclude with a discussion on where this work is

headed.

2 Ptrace-based Application Tracing

Like many other ﬂavors of UNIX, Linux provides the

ptrace system-call interface for tracing a running pro-

cess. This interface was designed mainly for debugging,

but it has been used for tracing purposes as well. This

section surveys some of the ptrace-based tracing tools

and presents limitations of the ptrace approach for low-

impact tracing.

Ptrace supports the following types of requests:

• Attach to, or detach from, the process being traced

(the “tracee”).

• Read or write the process’s memory, saved regis-

ters, or user area.

• Continue execution of the process, possibly until a

particular type of event occurs (e.g., a system call

is called or returns).

• 215 •

216 • Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User Apps

Events in the tracee turn into SIGCHLD signals that

are delivered to the tracing process. The associated

siginfo_t speciﬁes the type of event.

2.1 Gdb

gdb is the most widely used application debugger in

Linux, and it runs on other ﬂavors of UNIX as well.

gdb controls the program to be debugged using ptrace

requests. gdb is used mostly as an interactive debugger,

but also provides a batch option through which a series

of gdb commands can be executed, without user inter-

vention, each time a breakpoint is hit. This method of

tracing has signiﬁcant performance overhead. gdb’s ap-

proach to tracing multithreaded applications is to stop

all threads whenever any thread hits a breakpoint.

2.2 Strace

The strace command provides the ability to trace calls

and returns from all the system calls executed by

the traced process. strace exploits ptrace’s PTRACE_

SYSCALL request, which directs ptrace to continue ex-

ecution of the tracee until the next entry or exit from a

system call. strace handles multithreaded applications

well, and it has signiﬁcantly less performance overhead

than the gdb scripting method; but performance is still

the number-one complaint about strace. Using strace

to trace itself shows that each system call in the tracee

yields several system calls in strace.

2.3 Ltrace

The ltrace command is similar to strace, but it traces

calls and returns from dynamic library functions. It can

also trace system calls, and extern functions in the traced

program itself. ltrace uses ptrace to place breakpoints at

the entry point and return address of each probed func-

tion. ltrace is a useful tool, but it suffers from the per-

formance limitations inherent in ptrace-based tools. It

also appears not to work for multithreaded programs.

2.4 Ptrace Limitations

If gdb, strace, and ltrace don’t give you the type of in-

formation you’re looking for, you might consider writ-

ing your own ptrace-based tracing tool. But consider the

following ptrace limitations ﬁrst:

• Ptrace is not a POSIX system call. Its behavior

varies from operating system to operating system,

and has even varied from version to version in

Linux. Vital operational details (“Why do I get two

SIGCHLDs here? Am I supposed to pass the pro-

cess a SIGCONT or no signal at all here?”) are not

documented, and are not easily gleaned from the

kernel source.

• The amount of perseverence and/or luck you need

to get a working program goes up as you try to

monitor more than one process or more than one

thread.

• Overheads associated with accessing the tracee’s

memory and registers are enormous—on the order

of 10x to 100x or more, compared with equivalent

in-kernel access. Ptrace’s PEEK-and-POKE inter-

face provides very low bandwidth and incurs nu-

merous context switches.

• In order to trace a process, the tracer must become

the tracee’s parent. To attach to an already run-

ning process, then, the tracer must muck with the

tracee’s lineage. Also, if you decide you want to

apply more instrumentation to the same process,

you have to detach the tracer already in place.

3 Kernel-based Tracing

In the early days of Linux, the kernel code base was

manageable and most people working on the kernel

knew their core areas intimately. There was a deﬁnite

pushback from the kernel community towards including

any tracing and/or debugging features in the mainline

kernel.

Over time, Linux became more popular and the num-

ber of kernel contributors increased. A need for a ﬂexi-

ble tracing infrastructure was recognized. To that end, a

number of projects sprung up and have achieved varied

degrees of success.

We will look at a few of these projects in this section.

Most of them are based on the kernel-module approach.

3.1 Kernel-module approach

The common thread among the following approaches

is that the instrumentation code needs to run in kernel

2007 Linux Symposium, Volume One • 217

mode. Since we wouldn’t want to burden the kernel at

times when the instrumentation isn’t in use, such code

is introduced only when needed, in the form of a kernel

module.

3.1.1 Kprobes

Kprobes [2] is perhaps the most widely accepted of all

dynamic instrumentation mechanisms currently avail-

able for the Linux kernel. Kprobes traces its roots back

to DProbes (discussed later). In fact, the ﬁrst version of

kprobes was a patch created by just taking the minimal,

kernel-only portions of the DProbes framework.

Kprobes allows a user to dynamically insert “probes”

into speciﬁc locations in the Linux kernel. The user

speciﬁes “handlers” (instrumentation functions) that run

before and/or after the probed instruction is executed.

When a probepoint (which typically is an architecture-

speciﬁc breakpoint instruction) is hit, control is passed

to the kprobes infrastructure, which takes care of execut-

ing the user-speciﬁed handlers. [2] provides an in-depth

treatment of the kprobes infrastructure (which, inciden-

tally, includes jprobes and function-return probes).

The kernel-module approach was a natural choice for

kprobes: after all, the goal is to access and instrument

the Linux kernel. Given the privilege and safety re-

quirements necessary to access kernel data structures,

the kernel-module approach works very well.

3.1.2 Utrace

A relatively new entrant to this instrumentation space

is utrace. This infrastructure is intended to serve as an

abstraction layer to write the next generation of user-

space tracing and debugging applications.

One of the primary grouses kernel hackers have had

about ptrace is the lack of separation/layering of

code between architecture-speciﬁc and -agnostic parts.

Utrace aims to mitigate this situation. Ptrace is now but

one of the clients of utrace.

Utrace, at a very basic level, is an infrastructure to mon-

itor individual Linux “threads”—each represented by a

task_struct in the kernel. An “engine” is utrace’s

basic control unit. Typically, each utrace client estab-

lishes an engine for each thread of interest. Utrace pro-

vides three basic facilities on a per-engine basis:

• Event reporting: Utrace clients register callbacks

to be run when the thread encounters speciﬁc

events of interest. These include system call en-

try/exit, signals, exec, clone, exit, etc.

• Thread control: Utrace clients can inject signals,

request that a thread be stopped from running in

user-space, single-step, block-step, etc.

• Thread machine state access: While in a callback,

a client can inspect and/or modify the thread’s core

state, including the registers and u-area.

Utrace works by placing tracepoints at strategic points in

kernel code. For traced threads, these tracepoints yield

calls into the registered utrace clients. These callbacks,

though happening in the context of a user process, hap-

pen when the process is executing in kernel mode. In

other words, utrace clients run in the kernel. Ptrace is

one utrace client that lives in the kernel. Other clients—

especially those used for ad hoc instrumentation—may

be implemented as kernel modules.

3.1.3 Uprobes

Uprobes is another client of utrace. As such, uprobes

can be seen as a ﬂexible user-space probing mecha-

nism that comes with all the power, but not all the con-

straints, of ptrace. Just as kprobes creates and manages

probepoints in kernel code, uprobes creates and man-

ages probepoints in user applications. The uprobes in-

frastructure, like ptrace, lives in the kernel.

A uprobes user writes a kernel module, specifying for

each desired probepoint the process and virtual address

to be probed and the handler to run when the probepoint

is hit.

A uprobes-based module can also use the utrace and/or

kprobes APIs. Thus a single instrumentation module

can collect and correlate information from the user ap-

plication(s), shared libraries, the kernel/user interfaces,

and the kernel itself.

3.1.4 SystemTap

SystemTap [4] provides a mechanism to use the kernel

(and later, user) instrumentation tools, through a simple

剩余11页未读，继续阅读

评论收藏

内容反馈

c1_wangyf

2013-05-10

对我的用处不大

batizty2001

粉丝: 6
资源: 14

Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User Ap...

最新资源

Ptrace, Utrace, Uprobes: Lightweight, Dynamic Tracing of User Ap...

ptrace安卓程序注入例子

Python-ptracer一个用于Python程序的基于ptrace跟踪的库

论文研究-Linux下Ptrace()调用的安全分析.pdf

weaver:使用uprobes和eBPF跟踪Go程序执行

chrome://tracing说明

Peter Shirley Ray Tracing系列合集

去掉AlipayWallet的ptrace 反调试保护，进行lldb调试（学习demo）

python-ptrace:python-ptrace是ptrace库的Python绑定

ptrace注入实例

ptrace的小demo

utrace:移动应用程序的远程调试控制台

utrace：为OpenGrok生成HTML形式的函数调用跟踪，或为GraphViz DOT生成一个调用图

Linux下Ptrace()调用的安全分析.pdf

GDB & ptrace() System Call

Ptrace-for-Android:一个用户级调试应用程序，可以跟踪 Android 中正在运行的应用程序

利用Ptrace在Android平台实现应用程序控制

pTrace:一种面向可控云计算的DDos攻击源控制技术

ptrace防护.zip

goldfish:Linux 的实时进程内存查看器

5.ptrace注入与zygote区别和联系.V2EE

ptrace:一个用于Linux的PoC，可以绕过代理，该代理记录了正在执行的命令，没有root特权。 Linux低权限模糊化执行的程序名和参数，避开基于execve系统调用监控的命令日志

letmedebug:禁用ptrace的PT_DENY_ATTACH-修补ptrace系统调用

appfence:Android沙箱（基于ptrace）

PTRACE函数代码分析

python大作业 含爬虫、数据可视化、地图、报告、及源码（整和为一个文件）（2014-2020全国各地区原油加工量）.rar

仿真电路以及操作方法

【纯干货啊】华为IPD流程管理(完整版).pptx

可编程语言标准IEC61131-3中文版.pdf

OFDM完整仿真过程与教程.zip

最新资源

python大作业含爬虫、数据可视化、地图、报告、及源码（整和为一个文件）（2014-2020全国各地区原油加工量）.rar