2005-04-17 06:20:36 +08:00
|
|
|
#ifndef _LINUX_PTRACE_H
|
|
|
|
#define _LINUX_PTRACE_H
|
|
|
|
|
2012-10-13 17:46:48 +08:00
|
|
|
#include <linux/compiler.h> /* For unlikely. */
|
|
|
|
#include <linux/sched.h> /* For struct task_struct. */
|
2017-02-09 01:51:30 +08:00
|
|
|
#include <linux/sched/signal.h> /* For send_sig(), same_thread_group(), etc. */
|
2012-10-13 17:46:48 +08:00
|
|
|
#include <linux/err.h> /* for IS_ERR_VALUE */
|
|
|
|
#include <linux/bug.h> /* For BUG_ON. */
|
2014-06-07 05:36:42 +08:00
|
|
|
#include <linux/pid_namespace.h> /* For task_active_pid_ns. */
|
2012-10-13 17:46:48 +08:00
|
|
|
#include <uapi/linux/ptrace.h>
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2016-11-23 02:06:50 +08:00
|
|
|
extern int ptrace_access_vm(struct task_struct *tsk, unsigned long addr,
|
|
|
|
void *buf, int len, unsigned int gup_flags);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/*
|
|
|
|
* Ptrace flags
|
2006-06-23 17:05:18 +08:00
|
|
|
*
|
|
|
|
* The owner ship rules for task->ptrace which holds the ptrace
|
|
|
|
* flags is simple. When a task is running it owns it's task->ptrace
|
|
|
|
* flags. When the a task is stopped the ptracer owns task->ptrace.
|
2005-04-17 06:20:36 +08:00
|
|
|
*/
|
|
|
|
|
ptrace: implement PTRACE_SEIZE
PTRACE_ATTACH implicitly issues SIGSTOP on attach which has side
effects on tracee signal and job control states. This patch
implements a new ptrace request PTRACE_SEIZE which attaches a tracee
without trapping it or affecting its signal and job control states.
The usage is the same with PTRACE_ATTACH but it takes PTRACE_SEIZE_*
flags in @data. Currently, the only defined flag is
PTRACE_SEIZE_DEVEL which is a temporary flag to enable PTRACE_SEIZE.
PTRACE_SEIZE will change ptrace behaviors outside of attach itself.
The changes will be implemented gradually and the DEVEL flag is to
prevent programs which expect full SEIZE behavior from using it before
all the behavior modifications are complete while allowing unit
testing. The flag will be removed once SEIZE behaviors are completely
implemented.
* PTRACE_SEIZE, unlike ATTACH, doesn't force tracee to trap. After
attaching tracee continues to run unless a trap condition occurs.
* PTRACE_SEIZE doesn't affect signal or group stop state.
* If PTRACE_SEIZE'd, group stop uses PTRACE_EVENT_STOP trap which uses
exit_code of (signr | PTRACE_EVENT_STOP << 8) where signr is one of
the stopping signals if group stop is in effect or SIGTRAP
otherwise, and returns usual trap siginfo on PTRACE_GETSIGINFO
instead of NULL.
Seizing sets PT_SEIZED in ->ptrace of the tracee. This flag will be
used to determine whether new SEIZE behaviors should be enabled.
Test program follows.
#define PTRACE_SEIZE 0x4206
#define PTRACE_SEIZE_DEVEL 0x80000000
static const struct timespec ts100ms = { .tv_nsec = 100000000 };
static const struct timespec ts1s = { .tv_sec = 1 };
static const struct timespec ts3s = { .tv_sec = 3 };
int main(int argc, char **argv)
{
pid_t tracee;
tracee = fork();
if (tracee == 0) {
nanosleep(&ts100ms, NULL);
while (1) {
printf("tracee: alive\n");
nanosleep(&ts1s, NULL);
}
}
if (argc > 1)
kill(tracee, SIGSTOP);
nanosleep(&ts100ms, NULL);
ptrace(PTRACE_SEIZE, tracee, NULL,
(void *)(unsigned long)PTRACE_SEIZE_DEVEL);
if (argc > 1) {
waitid(P_PID, tracee, NULL, WSTOPPED);
ptrace(PTRACE_CONT, tracee, NULL, NULL);
}
nanosleep(&ts3s, NULL);
printf("tracer: exiting\n");
return 0;
}
When the above program is called w/o argument, tracee is seized while
running and remains running. When tracer exits, tracee continues to
run and print out messages.
# ./test-seize-simple
tracee: alive
tracee: alive
tracee: alive
tracer: exiting
tracee: alive
tracee: alive
When called with an argument, tracee is seized from stopped state and
continued, and returns to stopped state when tracer exits.
# ./test-seize
tracee: alive
tracee: alive
tracee: alive
tracer: exiting
# ps -el|grep test-seize
1 T 0 4720 1 0 80 0 - 941 signal ttyS0 00:00:00 test-seize
-v2: SEIZE doesn't schedule TRAP_STOP and leaves tracee running as Jan
suggested.
-v3: PTRACE_EVENT_STOP traps now report group stop state by signr. If
group stop is in effect the stop signal number is returned as
part of exit_code; otherwise, SIGTRAP. This was suggested by
Denys and Oleg.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Jan Kratochvil <jan.kratochvil@redhat.com>
Cc: Denys Vlasenko <vda.linux@googlemail.com>
Cc: Oleg Nesterov <oleg@redhat.com>
2011-06-14 17:20:15 +08:00
|
|
|
#define PT_SEIZED 0x00010000 /* SEIZE used, enable new behavior */
|
2005-04-17 06:20:36 +08:00
|
|
|
#define PT_PTRACED 0x00000001
|
|
|
|
#define PT_DTRACE 0x00000002 /* delayed trace (used on m68k, i386) */
|
2011-06-17 22:50:35 +08:00
|
|
|
|
2012-03-24 06:02:41 +08:00
|
|
|
#define PT_OPT_FLAG_SHIFT 3
|
2011-06-17 22:50:35 +08:00
|
|
|
/* PT_TRACE_* event enable flags */
|
2012-03-24 06:02:41 +08:00
|
|
|
#define PT_EVENT_FLAG(event) (1 << (PT_OPT_FLAG_SHIFT + (event)))
|
|
|
|
#define PT_TRACESYSGOOD PT_EVENT_FLAG(0)
|
2011-06-17 22:50:35 +08:00
|
|
|
#define PT_TRACE_FORK PT_EVENT_FLAG(PTRACE_EVENT_FORK)
|
|
|
|
#define PT_TRACE_VFORK PT_EVENT_FLAG(PTRACE_EVENT_VFORK)
|
|
|
|
#define PT_TRACE_CLONE PT_EVENT_FLAG(PTRACE_EVENT_CLONE)
|
|
|
|
#define PT_TRACE_EXEC PT_EVENT_FLAG(PTRACE_EVENT_EXEC)
|
|
|
|
#define PT_TRACE_VFORK_DONE PT_EVENT_FLAG(PTRACE_EVENT_VFORK_DONE)
|
|
|
|
#define PT_TRACE_EXIT PT_EVENT_FLAG(PTRACE_EVENT_EXIT)
|
2012-04-13 05:48:02 +08:00
|
|
|
#define PT_TRACE_SECCOMP PT_EVENT_FLAG(PTRACE_EVENT_SECCOMP)
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2012-12-18 08:03:07 +08:00
|
|
|
#define PT_EXITKILL (PTRACE_O_EXITKILL << PT_OPT_FLAG_SHIFT)
|
seccomp: add ptrace options for suspend/resume
This patch is the first step in enabling checkpoint/restore of processes
with seccomp enabled.
One of the things CRIU does while dumping tasks is inject code into them
via ptrace to collect information that is only available to the process
itself. However, if we are in a seccomp mode where these processes are
prohibited from making these syscalls, then what CRIU does kills the task.
This patch adds a new ptrace option, PTRACE_O_SUSPEND_SECCOMP, that enables
a task from the init user namespace which has CAP_SYS_ADMIN and no seccomp
filters to disable (and re-enable) seccomp filters for another task so that
they can be successfully dumped (and restored). We restrict the set of
processes that can disable seccomp through ptrace because although today
ptrace can be used to bypass seccomp, there is some discussion of closing
this loophole in the future and we would like this patch to not depend on
that behavior and be future proofed for when it is removed.
Note that seccomp can be suspended before any filters are actually
installed; this behavior is useful on criu restore, so that we can suspend
seccomp, restore the filters, unmap our restore code from the restored
process' address space, and then resume the task by detaching and have the
filters resumed as well.
v2 changes:
* require that the tracer have no seccomp filters installed
* drop TIF_NOTSC manipulation from the patch
* change from ptrace command to a ptrace option and use this ptrace option
as the flag to check. This means that as soon as the tracer
detaches/dies, seccomp is re-enabled and as a corrollary that one can not
disable seccomp across PTRACE_ATTACHs.
v3 changes:
* get rid of various #ifdefs everywhere
* report more sensible errors when PTRACE_O_SUSPEND_SECCOMP is incorrectly
used
v4 changes:
* get rid of may_suspend_seccomp() in favor of a capable() check in ptrace
directly
v5 changes:
* check that seccomp is not enabled (or suspended) on the tracer
Signed-off-by: Tycho Andersen <tycho.andersen@canonical.com>
CC: Will Drewry <wad@chromium.org>
CC: Roland McGrath <roland@hack.frob.com>
CC: Pavel Emelyanov <xemul@parallels.com>
CC: Serge E. Hallyn <serge.hallyn@ubuntu.com>
Acked-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Andy Lutomirski <luto@amacapital.net>
[kees: access seccomp.mode through seccomp_mode() instead]
Signed-off-by: Kees Cook <keescook@chromium.org>
2015-06-13 23:02:48 +08:00
|
|
|
#define PT_SUSPEND_SECCOMP (PTRACE_O_SUSPEND_SECCOMP << PT_OPT_FLAG_SHIFT)
|
2012-12-18 08:03:07 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
/* single stepping state bits (used on ARM and PA-RISC) */
|
|
|
|
#define PT_SINGLESTEP_BIT 31
|
|
|
|
#define PT_SINGLESTEP (1<<PT_SINGLESTEP_BIT)
|
|
|
|
#define PT_BLOCKSTEP_BIT 30
|
|
|
|
#define PT_BLOCKSTEP (1<<PT_BLOCKSTEP_BIT)
|
|
|
|
|
2010-10-28 06:33:47 +08:00
|
|
|
extern long arch_ptrace(struct task_struct *child, long request,
|
|
|
|
unsigned long addr, unsigned long data);
|
2005-04-17 06:20:36 +08:00
|
|
|
extern int ptrace_readdata(struct task_struct *tsk, unsigned long src, char __user *dst, int len);
|
|
|
|
extern int ptrace_writedata(struct task_struct *tsk, char __user *src, unsigned long dst, int len);
|
|
|
|
extern void ptrace_disable(struct task_struct *);
|
2010-10-28 06:33:45 +08:00
|
|
|
extern int ptrace_request(struct task_struct *child, long request,
|
|
|
|
unsigned long addr, unsigned long data);
|
2005-04-17 06:20:36 +08:00
|
|
|
extern void ptrace_notify(int exit_code);
|
|
|
|
extern void __ptrace_link(struct task_struct *child,
|
|
|
|
struct task_struct *new_parent);
|
|
|
|
extern void __ptrace_unlink(struct task_struct *child);
|
2014-12-11 07:45:33 +08:00
|
|
|
extern void exit_ptrace(struct task_struct *tracer, struct list_head *dead);
|
2012-01-04 01:25:15 +08:00
|
|
|
#define PTRACE_MODE_READ 0x01
|
|
|
|
#define PTRACE_MODE_ATTACH 0x02
|
|
|
|
#define PTRACE_MODE_NOAUDIT 0x04
|
ptrace: use fsuid, fsgid, effective creds for fs access checks
By checking the effective credentials instead of the real UID / permitted
capabilities, ensure that the calling process actually intended to use its
credentials.
To ensure that all ptrace checks use the correct caller credentials (e.g.
in case out-of-tree code or newly added code omits the PTRACE_MODE_*CREDS
flag), use two new flags and require one of them to be set.
The problem was that when a privileged task had temporarily dropped its
privileges, e.g. by calling setreuid(0, user_uid), with the intent to
perform following syscalls with the credentials of a user, it still passed
ptrace access checks that the user would not be able to pass.
While an attacker should not be able to convince the privileged task to
perform a ptrace() syscall, this is a problem because the ptrace access
check is reused for things in procfs.
In particular, the following somewhat interesting procfs entries only rely
on ptrace access checks:
/proc/$pid/stat - uses the check for determining whether pointers
should be visible, useful for bypassing ASLR
/proc/$pid/maps - also useful for bypassing ASLR
/proc/$pid/cwd - useful for gaining access to restricted
directories that contain files with lax permissions, e.g. in
this scenario:
lrwxrwxrwx root root /proc/13020/cwd -> /root/foobar
drwx------ root root /root
drwxr-xr-x root root /root/foobar
-rw-r--r-- root root /root/foobar/secret
Therefore, on a system where a root-owned mode 6755 binary changes its
effective credentials as described and then dumps a user-specified file,
this could be used by an attacker to reveal the memory layout of root's
processes or reveal the contents of files he is not allowed to access
(through /proc/$pid/cwd).
[akpm@linux-foundation.org: fix warning]
Signed-off-by: Jann Horn <jann@thejh.net>
Acked-by: Kees Cook <keescook@chromium.org>
Cc: Casey Schaufler <casey@schaufler-ca.com>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: James Morris <james.l.morris@oracle.com>
Cc: "Serge E. Hallyn" <serge.hallyn@ubuntu.com>
Cc: Andy Shevchenko <andriy.shevchenko@linux.intel.com>
Cc: Andy Lutomirski <luto@kernel.org>
Cc: Al Viro <viro@zeniv.linux.org.uk>
Cc: "Eric W. Biederman" <ebiederm@xmission.com>
Cc: Willy Tarreau <w@1wt.eu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2016-01-21 07:00:04 +08:00
|
|
|
#define PTRACE_MODE_FSCREDS 0x08
|
|
|
|
#define PTRACE_MODE_REALCREDS 0x10
|
|
|
|
|
|
|
|
/* shorthands for READ/ATTACH and FSCREDS/REALCREDS combinations */
|
|
|
|
#define PTRACE_MODE_READ_FSCREDS (PTRACE_MODE_READ | PTRACE_MODE_FSCREDS)
|
|
|
|
#define PTRACE_MODE_READ_REALCREDS (PTRACE_MODE_READ | PTRACE_MODE_REALCREDS)
|
|
|
|
#define PTRACE_MODE_ATTACH_FSCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_FSCREDS)
|
|
|
|
#define PTRACE_MODE_ATTACH_REALCREDS (PTRACE_MODE_ATTACH | PTRACE_MODE_REALCREDS)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ptrace_may_access - check whether the caller is permitted to access
|
|
|
|
* a target task.
|
|
|
|
* @task: target task
|
|
|
|
* @mode: selects type of access and caller credentials
|
|
|
|
*
|
|
|
|
* Returns true on success, false on denial.
|
|
|
|
*
|
|
|
|
* One of the flags PTRACE_MODE_FSCREDS and PTRACE_MODE_REALCREDS must
|
|
|
|
* be set in @mode to specify whether the access was requested through
|
|
|
|
* a filesystem syscall (should use effective capabilities and fsuid
|
|
|
|
* of the caller) or through an explicit syscall such as
|
|
|
|
* process_vm_writev or ptrace (and should use the real credentials).
|
|
|
|
*/
|
Security: split proc ptrace checking into read vs. attach
Enable security modules to distinguish reading of process state via
proc from full ptrace access by renaming ptrace_may_attach to
ptrace_may_access and adding a mode argument indicating whether only
read access or full attach access is requested. This allows security
modules to permit access to reading process state without granting
full ptrace access. The base DAC/capability checking remains unchanged.
Read access to /proc/pid/mem continues to apply a full ptrace attach
check since check_mem_permission() already requires the current task
to already be ptracing the target. The other ptrace checks within
proc for elements like environ, maps, and fds are changed to pass the
read mode instead of attach.
In the SELinux case, we model such reading of process state as a
reading of a proc file labeled with the target process' label. This
enables SELinux policy to permit such reading of process state without
permitting control or manipulation of the target process, as there are
a number of cases where programs probe for such information via proc
but do not need to be able to control the target (e.g. procps,
lsof, PolicyKit, ConsoleKit). At present we have to choose between
allowing full ptrace in policy (more permissive than required/desired)
or breaking functionality (or in some cases just silencing the denials
via dontaudit rules but this can hide genuine attacks).
This version of the patch incorporates comments from Casey Schaufler
(change/replace existing ptrace_may_attach interface, pass access
mode), and Chris Wright (provide greater consistency in the checking).
Note that like their predecessors __ptrace_may_attach and
ptrace_may_attach, the __ptrace_may_access and ptrace_may_access
interfaces use different return value conventions from each other (0
or -errno vs. 1 or 0). I retained this difference to avoid any
changes to the caller logic but made the difference clearer by
changing the latter interface to return a bool rather than an int and
by adding a comment about it to ptrace.h for any future callers.
Signed-off-by: Stephen Smalley <sds@tycho.nsa.gov>
Acked-by: Chris Wright <chrisw@sous-sol.org>
Signed-off-by: James Morris <jmorris@namei.org>
2008-05-19 20:32:49 +08:00
|
|
|
extern bool ptrace_may_access(struct task_struct *task, unsigned int mode);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2008-04-30 15:53:13 +08:00
|
|
|
static inline int ptrace_reparented(struct task_struct *child)
|
|
|
|
{
|
ptrace: ptrace_reparented() should check same_thread_group()
ptrace_reparented() naively does parent != real_parent, this means
it returns true even if the tracer _is_ the real parent. This is per
process thing, not per-thread. The only reason ->real_parent can
point to the non-leader thread is that we have __WNOTHREAD.
Change it to check !same_thread_group(parent, real_parent).
It has two callers, and in both cases the current check does not
look right.
exit_notify: we should respect ->exit_signal if the exiting leader
is traced by any thread from the parent thread group. It is the
child of the whole group, and we are going to send the signal to
the whole group.
wait_task_zombie: without __WNOTHREAD do_wait() should do the same
for any thread, only sys_ptrace() is "bound" to the single thread.
However do_wait(WEXITED) succeeds but does not release a traced
natural child unless the caller is the tracer.
Test-case:
void *tfunc(void *arg)
{
assert(ptrace(PTRACE_ATTACH, (long)arg, 0,0) == 0);
pause();
return NULL;
}
int main(void)
{
pthread_t thr;
pid_t pid, stat, ret;
pid = fork();
if (!pid) {
pause();
assert(0);
}
assert(pthread_create(&thr, NULL, tfunc, (void*)(long)pid) == 0);
assert(waitpid(-1, &stat, 0) == pid);
assert(WIFSTOPPED(stat));
kill(pid, SIGKILL);
assert(waitpid(-1, &stat, 0) == pid);
assert(WIFSIGNALED(stat) && WTERMSIG(stat) == SIGKILL);
ret = waitpid(pid, &stat, 0);
if (ret < 0)
return 0;
printf("WTF? %d is dead, but: wait=%d stat=%x\n",
pid, ret, stat);
return 1;
}
Note that the main thread simply does
pid = fork();
kill(pid, SIGKILL);
and then without the patch wait4(WEXITED) succeeds twice and reports
WTERMSIG(stat) == SIGKILL.
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Tejun Heo <tj@kernel.org>
2011-06-24 23:34:06 +08:00
|
|
|
return !same_thread_group(child->real_parent, child->parent);
|
2008-04-30 15:53:13 +08:00
|
|
|
}
|
2009-12-16 08:47:15 +08:00
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
static inline void ptrace_unlink(struct task_struct *child)
|
|
|
|
{
|
|
|
|
if (unlikely(child->ptrace))
|
|
|
|
__ptrace_unlink(child);
|
|
|
|
}
|
|
|
|
|
2010-10-28 06:33:45 +08:00
|
|
|
int generic_ptrace_peekdata(struct task_struct *tsk, unsigned long addr,
|
|
|
|
unsigned long data);
|
|
|
|
int generic_ptrace_pokedata(struct task_struct *tsk, unsigned long addr,
|
|
|
|
unsigned long data);
|
2005-04-17 06:20:36 +08:00
|
|
|
|
2011-06-17 22:50:40 +08:00
|
|
|
/**
|
|
|
|
* ptrace_parent - return the task that is tracing the given task
|
|
|
|
* @task: task to consider
|
|
|
|
*
|
|
|
|
* Returns %NULL if no one is tracing @task, or the &struct task_struct
|
|
|
|
* pointer to its tracer.
|
|
|
|
*
|
|
|
|
* Must called under rcu_read_lock(). The pointer returned might be kept
|
|
|
|
* live only by RCU. During exec, this may be called with task_lock() held
|
|
|
|
* on @task, still held from when check_unsafe_exec() was called.
|
|
|
|
*/
|
|
|
|
static inline struct task_struct *ptrace_parent(struct task_struct *task)
|
|
|
|
{
|
|
|
|
if (unlikely(task->ptrace))
|
|
|
|
return rcu_dereference(task->parent);
|
|
|
|
return NULL;
|
|
|
|
}
|
|
|
|
|
2011-06-17 22:50:35 +08:00
|
|
|
/**
|
|
|
|
* ptrace_event_enabled - test whether a ptrace event is enabled
|
|
|
|
* @task: ptracee of interest
|
|
|
|
* @event: %PTRACE_EVENT_* to test
|
|
|
|
*
|
|
|
|
* Test whether @event is enabled for ptracee @task.
|
|
|
|
*
|
|
|
|
* Returns %true if @event is enabled, %false otherwise.
|
|
|
|
*/
|
|
|
|
static inline bool ptrace_event_enabled(struct task_struct *task, int event)
|
|
|
|
{
|
|
|
|
return task->ptrace & PT_EVENT_FLAG(event);
|
|
|
|
}
|
|
|
|
|
tracehook: add linux/tracehook.h
This patch series introduces the "tracehook" interface layer of inlines in
<linux/tracehook.h>. There are more details in the log entry for patch
01/23 and in the header file comments inside that patch. Most of these
changes move code around with little or no change, and they should not
break anything or change any behavior.
This sets a new standard for uniform arch support to enable clean
arch-independent implementations of new debugging and tracing stuff,
denoted by CONFIG_HAVE_ARCH_TRACEHOOK. Patch 20/23 adds that symbol to
arch/Kconfig, with comments listing everything an arch has to do before
setting "select HAVE_ARCH_TRACEHOOK". These are elaborted a bit at:
http://sourceware.org/systemtap/wiki/utrace/arch/HowTo
The new inlines that arch code must define or call have detailed kerneldoc
comments in the generic header files that say what is required.
No arch is obligated to do any work, and no arch's build should be broken
by these changes. There are several steps that each arch should take so
it can set HAVE_ARCH_TRACEHOOK. Most of these are simple. Providing this
support will let new things people add for doing debugging and tracing of
user-level threads "just work" for your arch in the future. For an arch
that does not provide HAVE_ARCH_TRACEHOOK, some new options for such
features will not be available for config.
I have done some arch work and will submit this to the arch maintainers
after the generic tracehook series settles in. For now, that work is
available in my GIT repositories, and in patch and mbox-of-patches form at
http://people.redhat.com/roland/utrace/2.6-current/
This paves the way for my "utrace" work, to be submitted later. But it is
not innately tied to that. I hope that the tracehook series can go in
soon regardless of what eventually does or doesn't go on top of it. For
anyone implementing any kind of new tracing/debugging plan, or just
understanding all the context of the existing ptrace implementation,
having tracehook.h makes things much easier to find and understand.
This patch:
This adds the new kernel-internal header file <linux/tracehook.h>. This
is not yet used at all. The comments in the header introduce what the
following series of patches is about.
The aim is to formalize and consolidate all the places that the core
kernel code and the arch code now ties into the ptrace implementation.
These patches mostly don't cause any functional change. They just move
the details of ptrace logic out of core code into tracehook.h inlines,
where they are mostly compiled away to the same as before. All that
changes is that everything is thoroughly documented and any future
reworking of ptrace, or addition of something new, would not have to touch
core code all over, just change the tracehook.h inlines.
The new linux/ptrace.h inlines are used by the following patches in the
new tracehook_*() inlines. Using these helpers for the ptrace event stops
makes it simple to change or disable the old ptrace implementation of
these stops conditionally later.
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-26 10:45:43 +08:00
|
|
|
/**
|
|
|
|
* ptrace_event - possibly stop for a ptrace event notification
|
2011-06-17 22:50:35 +08:00
|
|
|
* @event: %PTRACE_EVENT_* value to report
|
tracehook: add linux/tracehook.h
This patch series introduces the "tracehook" interface layer of inlines in
<linux/tracehook.h>. There are more details in the log entry for patch
01/23 and in the header file comments inside that patch. Most of these
changes move code around with little or no change, and they should not
break anything or change any behavior.
This sets a new standard for uniform arch support to enable clean
arch-independent implementations of new debugging and tracing stuff,
denoted by CONFIG_HAVE_ARCH_TRACEHOOK. Patch 20/23 adds that symbol to
arch/Kconfig, with comments listing everything an arch has to do before
setting "select HAVE_ARCH_TRACEHOOK". These are elaborted a bit at:
http://sourceware.org/systemtap/wiki/utrace/arch/HowTo
The new inlines that arch code must define or call have detailed kerneldoc
comments in the generic header files that say what is required.
No arch is obligated to do any work, and no arch's build should be broken
by these changes. There are several steps that each arch should take so
it can set HAVE_ARCH_TRACEHOOK. Most of these are simple. Providing this
support will let new things people add for doing debugging and tracing of
user-level threads "just work" for your arch in the future. For an arch
that does not provide HAVE_ARCH_TRACEHOOK, some new options for such
features will not be available for config.
I have done some arch work and will submit this to the arch maintainers
after the generic tracehook series settles in. For now, that work is
available in my GIT repositories, and in patch and mbox-of-patches form at
http://people.redhat.com/roland/utrace/2.6-current/
This paves the way for my "utrace" work, to be submitted later. But it is
not innately tied to that. I hope that the tracehook series can go in
soon regardless of what eventually does or doesn't go on top of it. For
anyone implementing any kind of new tracing/debugging plan, or just
understanding all the context of the existing ptrace implementation,
having tracehook.h makes things much easier to find and understand.
This patch:
This adds the new kernel-internal header file <linux/tracehook.h>. This
is not yet used at all. The comments in the header introduce what the
following series of patches is about.
The aim is to formalize and consolidate all the places that the core
kernel code and the arch code now ties into the ptrace implementation.
These patches mostly don't cause any functional change. They just move
the details of ptrace logic out of core code into tracehook.h inlines,
where they are mostly compiled away to the same as before. All that
changes is that everything is thoroughly documented and any future
reworking of ptrace, or addition of something new, would not have to touch
core code all over, just change the tracehook.h inlines.
The new linux/ptrace.h inlines are used by the following patches in the
new tracehook_*() inlines. Using these helpers for the ptrace event stops
makes it simple to change or disable the old ptrace implementation of
these stops conditionally later.
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-26 10:45:43 +08:00
|
|
|
* @message: value for %PTRACE_GETEVENTMSG to return
|
|
|
|
*
|
2011-06-17 22:50:35 +08:00
|
|
|
* Check whether @event is enabled and, if so, report @event and @message
|
|
|
|
* to the ptrace parent.
|
tracehook: add linux/tracehook.h
This patch series introduces the "tracehook" interface layer of inlines in
<linux/tracehook.h>. There are more details in the log entry for patch
01/23 and in the header file comments inside that patch. Most of these
changes move code around with little or no change, and they should not
break anything or change any behavior.
This sets a new standard for uniform arch support to enable clean
arch-independent implementations of new debugging and tracing stuff,
denoted by CONFIG_HAVE_ARCH_TRACEHOOK. Patch 20/23 adds that symbol to
arch/Kconfig, with comments listing everything an arch has to do before
setting "select HAVE_ARCH_TRACEHOOK". These are elaborted a bit at:
http://sourceware.org/systemtap/wiki/utrace/arch/HowTo
The new inlines that arch code must define or call have detailed kerneldoc
comments in the generic header files that say what is required.
No arch is obligated to do any work, and no arch's build should be broken
by these changes. There are several steps that each arch should take so
it can set HAVE_ARCH_TRACEHOOK. Most of these are simple. Providing this
support will let new things people add for doing debugging and tracing of
user-level threads "just work" for your arch in the future. For an arch
that does not provide HAVE_ARCH_TRACEHOOK, some new options for such
features will not be available for config.
I have done some arch work and will submit this to the arch maintainers
after the generic tracehook series settles in. For now, that work is
available in my GIT repositories, and in patch and mbox-of-patches form at
http://people.redhat.com/roland/utrace/2.6-current/
This paves the way for my "utrace" work, to be submitted later. But it is
not innately tied to that. I hope that the tracehook series can go in
soon regardless of what eventually does or doesn't go on top of it. For
anyone implementing any kind of new tracing/debugging plan, or just
understanding all the context of the existing ptrace implementation,
having tracehook.h makes things much easier to find and understand.
This patch:
This adds the new kernel-internal header file <linux/tracehook.h>. This
is not yet used at all. The comments in the header introduce what the
following series of patches is about.
The aim is to formalize and consolidate all the places that the core
kernel code and the arch code now ties into the ptrace implementation.
These patches mostly don't cause any functional change. They just move
the details of ptrace logic out of core code into tracehook.h inlines,
where they are mostly compiled away to the same as before. All that
changes is that everything is thoroughly documented and any future
reworking of ptrace, or addition of something new, would not have to touch
core code all over, just change the tracehook.h inlines.
The new linux/ptrace.h inlines are used by the following patches in the
new tracehook_*() inlines. Using these helpers for the ptrace event stops
makes it simple to change or disable the old ptrace implementation of
these stops conditionally later.
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-26 10:45:43 +08:00
|
|
|
*
|
|
|
|
* Called without locks.
|
|
|
|
*/
|
2011-06-17 22:50:36 +08:00
|
|
|
static inline void ptrace_event(int event, unsigned long message)
|
tracehook: add linux/tracehook.h
This patch series introduces the "tracehook" interface layer of inlines in
<linux/tracehook.h>. There are more details in the log entry for patch
01/23 and in the header file comments inside that patch. Most of these
changes move code around with little or no change, and they should not
break anything or change any behavior.
This sets a new standard for uniform arch support to enable clean
arch-independent implementations of new debugging and tracing stuff,
denoted by CONFIG_HAVE_ARCH_TRACEHOOK. Patch 20/23 adds that symbol to
arch/Kconfig, with comments listing everything an arch has to do before
setting "select HAVE_ARCH_TRACEHOOK". These are elaborted a bit at:
http://sourceware.org/systemtap/wiki/utrace/arch/HowTo
The new inlines that arch code must define or call have detailed kerneldoc
comments in the generic header files that say what is required.
No arch is obligated to do any work, and no arch's build should be broken
by these changes. There are several steps that each arch should take so
it can set HAVE_ARCH_TRACEHOOK. Most of these are simple. Providing this
support will let new things people add for doing debugging and tracing of
user-level threads "just work" for your arch in the future. For an arch
that does not provide HAVE_ARCH_TRACEHOOK, some new options for such
features will not be available for config.
I have done some arch work and will submit this to the arch maintainers
after the generic tracehook series settles in. For now, that work is
available in my GIT repositories, and in patch and mbox-of-patches form at
http://people.redhat.com/roland/utrace/2.6-current/
This paves the way for my "utrace" work, to be submitted later. But it is
not innately tied to that. I hope that the tracehook series can go in
soon regardless of what eventually does or doesn't go on top of it. For
anyone implementing any kind of new tracing/debugging plan, or just
understanding all the context of the existing ptrace implementation,
having tracehook.h makes things much easier to find and understand.
This patch:
This adds the new kernel-internal header file <linux/tracehook.h>. This
is not yet used at all. The comments in the header introduce what the
following series of patches is about.
The aim is to formalize and consolidate all the places that the core
kernel code and the arch code now ties into the ptrace implementation.
These patches mostly don't cause any functional change. They just move
the details of ptrace logic out of core code into tracehook.h inlines,
where they are mostly compiled away to the same as before. All that
changes is that everything is thoroughly documented and any future
reworking of ptrace, or addition of something new, would not have to touch
core code all over, just change the tracehook.h inlines.
The new linux/ptrace.h inlines are used by the following patches in the
new tracehook_*() inlines. Using these helpers for the ptrace event stops
makes it simple to change or disable the old ptrace implementation of
these stops conditionally later.
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-26 10:45:43 +08:00
|
|
|
{
|
2011-06-17 22:50:36 +08:00
|
|
|
if (unlikely(ptrace_event_enabled(current, event))) {
|
|
|
|
current->ptrace_message = message;
|
|
|
|
ptrace_notify((event << 8) | SIGTRAP);
|
2012-03-24 06:02:40 +08:00
|
|
|
} else if (event == PTRACE_EVENT_EXEC) {
|
2011-06-17 22:50:36 +08:00
|
|
|
/* legacy EXEC report via SIGTRAP */
|
2012-03-24 06:02:40 +08:00
|
|
|
if ((current->ptrace & (PT_PTRACED|PT_SEIZED)) == PT_PTRACED)
|
|
|
|
send_sig(SIGTRAP, current, 0);
|
2011-06-17 22:50:36 +08:00
|
|
|
}
|
tracehook: add linux/tracehook.h
This patch series introduces the "tracehook" interface layer of inlines in
<linux/tracehook.h>. There are more details in the log entry for patch
01/23 and in the header file comments inside that patch. Most of these
changes move code around with little or no change, and they should not
break anything or change any behavior.
This sets a new standard for uniform arch support to enable clean
arch-independent implementations of new debugging and tracing stuff,
denoted by CONFIG_HAVE_ARCH_TRACEHOOK. Patch 20/23 adds that symbol to
arch/Kconfig, with comments listing everything an arch has to do before
setting "select HAVE_ARCH_TRACEHOOK". These are elaborted a bit at:
http://sourceware.org/systemtap/wiki/utrace/arch/HowTo
The new inlines that arch code must define or call have detailed kerneldoc
comments in the generic header files that say what is required.
No arch is obligated to do any work, and no arch's build should be broken
by these changes. There are several steps that each arch should take so
it can set HAVE_ARCH_TRACEHOOK. Most of these are simple. Providing this
support will let new things people add for doing debugging and tracing of
user-level threads "just work" for your arch in the future. For an arch
that does not provide HAVE_ARCH_TRACEHOOK, some new options for such
features will not be available for config.
I have done some arch work and will submit this to the arch maintainers
after the generic tracehook series settles in. For now, that work is
available in my GIT repositories, and in patch and mbox-of-patches form at
http://people.redhat.com/roland/utrace/2.6-current/
This paves the way for my "utrace" work, to be submitted later. But it is
not innately tied to that. I hope that the tracehook series can go in
soon regardless of what eventually does or doesn't go on top of it. For
anyone implementing any kind of new tracing/debugging plan, or just
understanding all the context of the existing ptrace implementation,
having tracehook.h makes things much easier to find and understand.
This patch:
This adds the new kernel-internal header file <linux/tracehook.h>. This
is not yet used at all. The comments in the header introduce what the
following series of patches is about.
The aim is to formalize and consolidate all the places that the core
kernel code and the arch code now ties into the ptrace implementation.
These patches mostly don't cause any functional change. They just move
the details of ptrace logic out of core code into tracehook.h inlines,
where they are mostly compiled away to the same as before. All that
changes is that everything is thoroughly documented and any future
reworking of ptrace, or addition of something new, would not have to touch
core code all over, just change the tracehook.h inlines.
The new linux/ptrace.h inlines are used by the following patches in the
new tracehook_*() inlines. Using these helpers for the ptrace event stops
makes it simple to change or disable the old ptrace implementation of
these stops conditionally later.
Signed-off-by: Roland McGrath <roland@redhat.com>
Cc: Oleg Nesterov <oleg@tv-sign.ru>
Reviewed-by: Ingo Molnar <mingo@elte.hu>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2008-07-26 10:45:43 +08:00
|
|
|
}
|
|
|
|
|
2014-06-07 05:36:42 +08:00
|
|
|
/**
|
|
|
|
* ptrace_event_pid - possibly stop for a ptrace event notification
|
|
|
|
* @event: %PTRACE_EVENT_* value to report
|
|
|
|
* @pid: process identifier for %PTRACE_GETEVENTMSG to return
|
|
|
|
*
|
|
|
|
* Check whether @event is enabled and, if so, report @event and @pid
|
|
|
|
* to the ptrace parent. @pid is reported as the pid_t seen from the
|
|
|
|
* the ptrace parent's pid namespace.
|
|
|
|
*
|
|
|
|
* Called without locks.
|
|
|
|
*/
|
|
|
|
static inline void ptrace_event_pid(int event, struct pid *pid)
|
|
|
|
{
|
|
|
|
/*
|
|
|
|
* FIXME: There's a potential race if a ptracer in a different pid
|
|
|
|
* namespace than parent attaches between computing message below and
|
|
|
|
* when we acquire tasklist_lock in ptrace_stop(). If this happens,
|
|
|
|
* the ptracer will get a bogus pid from PTRACE_GETEVENTMSG.
|
|
|
|
*/
|
|
|
|
unsigned long message = 0;
|
|
|
|
struct pid_namespace *ns;
|
|
|
|
|
|
|
|
rcu_read_lock();
|
|
|
|
ns = task_active_pid_ns(rcu_dereference(current->parent));
|
|
|
|
if (ns)
|
|
|
|
message = pid_nr_ns(pid, ns);
|
|
|
|
rcu_read_unlock();
|
|
|
|
|
|
|
|
ptrace_event(event, message);
|
|
|
|
}
|
|
|
|
|
2008-07-26 10:45:47 +08:00
|
|
|
/**
|
|
|
|
* ptrace_init_task - initialize ptrace state for a new child
|
|
|
|
* @child: new child task
|
|
|
|
* @ptrace: true if child should be ptrace'd by parent's tracer
|
|
|
|
*
|
|
|
|
* This is called immediately after adding @child to its parent's children
|
|
|
|
* list. @ptrace is false in the normal case, and true to ptrace @child.
|
|
|
|
*
|
|
|
|
* Called with current's siglock and write_lock_irq(&tasklist_lock) held.
|
|
|
|
*/
|
|
|
|
static inline void ptrace_init_task(struct task_struct *child, bool ptrace)
|
|
|
|
{
|
|
|
|
INIT_LIST_HEAD(&child->ptrace_entry);
|
|
|
|
INIT_LIST_HEAD(&child->ptraced);
|
2011-07-09 01:13:39 +08:00
|
|
|
child->jobctl = 0;
|
2008-07-26 10:45:47 +08:00
|
|
|
child->ptrace = 0;
|
2011-07-09 01:13:39 +08:00
|
|
|
child->parent = child->real_parent;
|
|
|
|
|
|
|
|
if (unlikely(ptrace) && current->ptrace) {
|
2008-07-26 10:45:47 +08:00
|
|
|
child->ptrace = current->ptrace;
|
2009-12-16 08:47:15 +08:00
|
|
|
__ptrace_link(child, current->parent);
|
2011-07-09 01:13:54 +08:00
|
|
|
|
ptrace: dont send SIGSTOP on auto-attach if PT_SEIZED
The fake SIGSTOP during attach has numerous problems. PTRACE_SEIZE
is already fine, but we have basically the same problems is SIGSTOP
is sent on auto-attach, the tracer can't know if this signal signal
should be cancelled or not.
Change ptrace_event() to set JOBCTL_TRAP_STOP if the new child is
PT_SEIZED, this triggers the PTRACE_EVENT_STOP report.
Thereafter a PT_SEIZED task can never report the bogus SIGSTOP.
Test-case:
#define PTRACE_SEIZE 0x4206
#define PTRACE_SEIZE_DEVEL 0x80000000
#define PTRACE_EVENT_STOP 7
#define WEVENT(s) ((s & 0xFF0000) >> 16)
int main(void)
{
int child, grand_child, status;
long message;
child = fork();
if (!child) {
kill(getpid(), SIGSTOP);
fork();
assert(0);
return 0x23;
}
assert(ptrace(PTRACE_SEIZE, child, 0,PTRACE_SEIZE_DEVEL) == 0);
assert(wait(&status) == child);
assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGSTOP);
assert(ptrace(PTRACE_SETOPTIONS, child, 0, PTRACE_O_TRACEFORK) == 0);
assert(ptrace(PTRACE_CONT, child, 0,0) == 0);
assert(waitpid(child, &status, 0) == child);
assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP);
assert(WEVENT(status) == PTRACE_EVENT_FORK);
assert(ptrace(PTRACE_GETEVENTMSG, child, 0, &message) == 0);
grand_child = message;
assert(waitpid(grand_child, &status, 0) == grand_child);
assert(WIFSTOPPED(status) && WSTOPSIG(status) == SIGTRAP);
assert(WEVENT(status) == PTRACE_EVENT_STOP);
kill(child, SIGKILL);
kill(grand_child, SIGKILL);
return 0;
}
Signed-off-by: Oleg Nesterov <oleg@redhat.com>
Acked-by: Tejun Heo <tj@kernel.org>
2011-07-09 01:14:17 +08:00
|
|
|
if (child->ptrace & PT_SEIZED)
|
|
|
|
task_set_jobctl_pending(child, JOBCTL_TRAP_STOP);
|
|
|
|
else
|
|
|
|
sigaddset(&child->pending.signal, SIGSTOP);
|
|
|
|
|
2011-07-09 01:13:54 +08:00
|
|
|
set_tsk_thread_flag(child, TIF_SIGPENDING);
|
2008-07-26 10:45:47 +08:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2008-07-26 10:45:48 +08:00
|
|
|
/**
|
|
|
|
* ptrace_release_task - final ptrace-related cleanup of a zombie being reaped
|
|
|
|
* @task: task in %EXIT_DEAD state
|
|
|
|
*
|
|
|
|
* Called with write_lock(&tasklist_lock) held.
|
|
|
|
*/
|
|
|
|
static inline void ptrace_release_task(struct task_struct *task)
|
|
|
|
{
|
|
|
|
BUG_ON(!list_empty(&task->ptraced));
|
|
|
|
ptrace_unlink(task);
|
|
|
|
BUG_ON(!list_empty(&task->ptrace_entry));
|
|
|
|
}
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#ifndef force_successful_syscall_return
|
|
|
|
/*
|
|
|
|
* System call handlers that, upon successful completion, need to return a
|
|
|
|
* negative value should call force_successful_syscall_return() right before
|
|
|
|
* returning. On architectures where the syscall convention provides for a
|
|
|
|
* separate error flag (e.g., alpha, ia64, ppc{,64}, sparc{,64}, possibly
|
|
|
|
* others), this macro can be used to ensure that the error flag will not get
|
|
|
|
* set. On architectures which do not support a separate error flag, the macro
|
|
|
|
* is a no-op and the spurious error condition needs to be filtered out by some
|
|
|
|
* other means (e.g., in user-level, by passing an extra argument to the
|
|
|
|
* syscall handler, or something along those lines).
|
|
|
|
*/
|
|
|
|
#define force_successful_syscall_return() do { } while (0)
|
|
|
|
#endif
|
|
|
|
|
2012-01-04 03:23:06 +08:00
|
|
|
#ifndef is_syscall_success
|
|
|
|
/*
|
|
|
|
* On most systems we can tell if a syscall is a success based on if the retval
|
|
|
|
* is an error value. On some systems like ia64 and powerpc they have different
|
|
|
|
* indicators of success/failure and must define their own.
|
|
|
|
*/
|
|
|
|
#define is_syscall_success(regs) (!IS_ERR_VALUE((unsigned long)(regs_return_value(regs))))
|
|
|
|
#endif
|
|
|
|
|
2008-01-30 20:30:47 +08:00
|
|
|
/*
|
|
|
|
* <asm/ptrace.h> should define the following things inside #ifdef __KERNEL__.
|
|
|
|
*
|
|
|
|
* These do-nothing inlines are used when the arch does not
|
|
|
|
* implement single-step. The kerneldoc comments are here
|
|
|
|
* to document the interface for all arch definitions.
|
|
|
|
*/
|
|
|
|
|
|
|
|
#ifndef arch_has_single_step
|
|
|
|
/**
|
|
|
|
* arch_has_single_step - does this CPU support user-mode single-step?
|
|
|
|
*
|
|
|
|
* If this is defined, then there must be function declarations or
|
|
|
|
* inlines for user_enable_single_step() and user_disable_single_step().
|
|
|
|
* arch_has_single_step() should evaluate to nonzero iff the machine
|
|
|
|
* supports instruction single-step for user mode.
|
|
|
|
* It can be a constant or it can test a CPU feature bit.
|
|
|
|
*/
|
|
|
|
#define arch_has_single_step() (0)
|
|
|
|
|
|
|
|
/**
|
|
|
|
* user_enable_single_step - single-step in user-mode task
|
|
|
|
* @task: either current or a task stopped in %TASK_TRACED
|
|
|
|
*
|
|
|
|
* This can only be called when arch_has_single_step() has returned nonzero.
|
|
|
|
* Set @task so that when it returns to user mode, it will trap after the
|
2008-01-30 20:30:53 +08:00
|
|
|
* next single instruction executes. If arch_has_block_step() is defined,
|
|
|
|
* this must clear the effects of user_enable_block_step() too.
|
2008-01-30 20:30:47 +08:00
|
|
|
*/
|
|
|
|
static inline void user_enable_single_step(struct task_struct *task)
|
|
|
|
{
|
|
|
|
BUG(); /* This can never be called. */
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* user_disable_single_step - cancel user-mode single-step
|
|
|
|
* @task: either current or a task stopped in %TASK_TRACED
|
|
|
|
*
|
2008-01-30 20:30:53 +08:00
|
|
|
* Clear @task of the effects of user_enable_single_step() and
|
|
|
|
* user_enable_block_step(). This can be called whether or not either
|
|
|
|
* of those was ever called on @task, and even if arch_has_single_step()
|
|
|
|
* returned zero.
|
2008-01-30 20:30:47 +08:00
|
|
|
*/
|
|
|
|
static inline void user_disable_single_step(struct task_struct *task)
|
|
|
|
{
|
|
|
|
}
|
ptrace: move user_enable_single_step & co prototypes to linux/ptrace.h
While in theory user_enable_single_step/user_disable_single_step/
user_enable_blockstep could also be provided as an inline or macro there's
no good reason to do so, and having the prototype in one places keeps code
size and confusion down.
Roland said:
The original thought there was that user_enable_single_step() et al
might well be only an instruction or three on a sane machine (as if we
have any of those!), and since there is only one call site inlining
would be beneficial. But I agree that there is no strong reason to care
about inlining it.
As to the arch changes, there is only one thought I'd add to the
record. It was always my thinking that for an arch where
PTRACE_SINGLESTEP does text-modifying breakpoint insertion,
user_enable_single_step() should not be provided. That is,
arch_has_single_step()=>true means that there is an arch facility with
"pure" semantics that does not have any unexpected side effects.
Inserting a breakpoint might do very unexpected strange things in
multi-threaded situations. Aside from that, it is a peculiar side
effect that user_{enable,disable}_single_step() should cause COW
de-sharing of text pages and so forth. For PTRACE_SINGLESTEP, all these
peculiarities are the status quo ante for that arch, so having
arch_ptrace() itself do those is one thing. But for building other
things in the future, it is nicer to have a uniform "pure" semantics
that arch-independent code can expect.
OTOH, all such arch issues are really up to the arch maintainer. As
of today, there is nothing but ptrace using user_enable_single_step() et
al so it's a distinction without a practical difference. If/when there
are other facilities that use user_enable_single_step() and might care,
the affected arch's can revisit the question when someone cares about
the quality of the arch support for said new facility.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-11 07:22:46 +08:00
|
|
|
#else
|
|
|
|
extern void user_enable_single_step(struct task_struct *);
|
|
|
|
extern void user_disable_single_step(struct task_struct *);
|
2008-01-30 20:30:47 +08:00
|
|
|
#endif /* arch_has_single_step */
|
|
|
|
|
2008-01-30 20:30:53 +08:00
|
|
|
#ifndef arch_has_block_step
|
|
|
|
/**
|
|
|
|
* arch_has_block_step - does this CPU support user-mode block-step?
|
|
|
|
*
|
|
|
|
* If this is defined, then there must be a function declaration or inline
|
|
|
|
* for user_enable_block_step(), and arch_has_single_step() must be defined
|
|
|
|
* too. arch_has_block_step() should evaluate to nonzero iff the machine
|
|
|
|
* supports step-until-branch for user mode. It can be a constant or it
|
|
|
|
* can test a CPU feature bit.
|
|
|
|
*/
|
2008-01-30 20:30:53 +08:00
|
|
|
#define arch_has_block_step() (0)
|
2008-01-30 20:30:53 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* user_enable_block_step - step until branch in user-mode task
|
|
|
|
* @task: either current or a task stopped in %TASK_TRACED
|
|
|
|
*
|
|
|
|
* This can only be called when arch_has_block_step() has returned nonzero,
|
|
|
|
* and will never be called when single-instruction stepping is being used.
|
|
|
|
* Set @task so that when it returns to user mode, it will trap after the
|
|
|
|
* next branch or trap taken.
|
|
|
|
*/
|
|
|
|
static inline void user_enable_block_step(struct task_struct *task)
|
|
|
|
{
|
|
|
|
BUG(); /* This can never be called. */
|
|
|
|
}
|
ptrace: move user_enable_single_step & co prototypes to linux/ptrace.h
While in theory user_enable_single_step/user_disable_single_step/
user_enable_blockstep could also be provided as an inline or macro there's
no good reason to do so, and having the prototype in one places keeps code
size and confusion down.
Roland said:
The original thought there was that user_enable_single_step() et al
might well be only an instruction or three on a sane machine (as if we
have any of those!), and since there is only one call site inlining
would be beneficial. But I agree that there is no strong reason to care
about inlining it.
As to the arch changes, there is only one thought I'd add to the
record. It was always my thinking that for an arch where
PTRACE_SINGLESTEP does text-modifying breakpoint insertion,
user_enable_single_step() should not be provided. That is,
arch_has_single_step()=>true means that there is an arch facility with
"pure" semantics that does not have any unexpected side effects.
Inserting a breakpoint might do very unexpected strange things in
multi-threaded situations. Aside from that, it is a peculiar side
effect that user_{enable,disable}_single_step() should cause COW
de-sharing of text pages and so forth. For PTRACE_SINGLESTEP, all these
peculiarities are the status quo ante for that arch, so having
arch_ptrace() itself do those is one thing. But for building other
things in the future, it is nicer to have a uniform "pure" semantics
that arch-independent code can expect.
OTOH, all such arch issues are really up to the arch maintainer. As
of today, there is nothing but ptrace using user_enable_single_step() et
al so it's a distinction without a practical difference. If/when there
are other facilities that use user_enable_single_step() and might care,
the affected arch's can revisit the question when someone cares about
the quality of the arch support for said new facility.
Signed-off-by: Christoph Hellwig <hch@lst.de>
Cc: Oleg Nesterov <oleg@redhat.com>
Cc: Roland McGrath <roland@redhat.com>
Acked-by: David Howells <dhowells@redhat.com>
Signed-off-by: Andrew Morton <akpm@linux-foundation.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
2010-03-11 07:22:46 +08:00
|
|
|
#else
|
|
|
|
extern void user_enable_block_step(struct task_struct *);
|
2008-01-30 20:30:53 +08:00
|
|
|
#endif /* arch_has_block_step */
|
|
|
|
|
2009-12-16 08:47:17 +08:00
|
|
|
#ifdef ARCH_HAS_USER_SINGLE_STEP_INFO
|
|
|
|
extern void user_single_step_siginfo(struct task_struct *tsk,
|
|
|
|
struct pt_regs *regs, siginfo_t *info);
|
|
|
|
#else
|
|
|
|
static inline void user_single_step_siginfo(struct task_struct *tsk,
|
|
|
|
struct pt_regs *regs, siginfo_t *info)
|
|
|
|
{
|
|
|
|
memset(info, 0, sizeof(*info));
|
|
|
|
info->si_signo = SIGTRAP;
|
|
|
|
}
|
|
|
|
#endif
|
|
|
|
|
2008-02-06 17:37:37 +08:00
|
|
|
#ifndef arch_ptrace_stop_needed
|
|
|
|
/**
|
|
|
|
* arch_ptrace_stop_needed - Decide whether arch_ptrace_stop() should be called
|
|
|
|
* @code: current->exit_code value ptrace will stop with
|
|
|
|
* @info: siginfo_t pointer (or %NULL) for signal ptrace will stop with
|
|
|
|
*
|
|
|
|
* This is called with the siglock held, to decide whether or not it's
|
|
|
|
* necessary to release the siglock and call arch_ptrace_stop() with the
|
|
|
|
* same @code and @info arguments. It can be defined to a constant if
|
|
|
|
* arch_ptrace_stop() is never required, or always is. On machines where
|
|
|
|
* this makes sense, it should be defined to a quick test to optimize out
|
|
|
|
* calling arch_ptrace_stop() when it would be superfluous. For example,
|
|
|
|
* if the thread has not been back to user mode since the last stop, the
|
|
|
|
* thread state might indicate that nothing needs to be done.
|
2014-07-04 03:43:15 +08:00
|
|
|
*
|
|
|
|
* This is guaranteed to be invoked once before a task stops for ptrace and
|
|
|
|
* may include arch-specific operations necessary prior to a ptrace stop.
|
2008-02-06 17:37:37 +08:00
|
|
|
*/
|
|
|
|
#define arch_ptrace_stop_needed(code, info) (0)
|
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef arch_ptrace_stop
|
|
|
|
/**
|
|
|
|
* arch_ptrace_stop - Do machine-specific work before stopping for ptrace
|
|
|
|
* @code: current->exit_code value ptrace will stop with
|
|
|
|
* @info: siginfo_t pointer (or %NULL) for signal ptrace will stop with
|
|
|
|
*
|
|
|
|
* This is called with no locks held when arch_ptrace_stop_needed() has
|
|
|
|
* just returned nonzero. It is allowed to block, e.g. for user memory
|
|
|
|
* access. The arch can have machine-specific work to be done before
|
|
|
|
* ptrace stops. On ia64, register backing store gets written back to user
|
|
|
|
* memory here. Since this can be costly (requires dropping the siglock),
|
|
|
|
* we only do it when the arch requires it for this particular stop, as
|
|
|
|
* indicated by arch_ptrace_stop_needed().
|
|
|
|
*/
|
|
|
|
#define arch_ptrace_stop(code, info) do { } while (0)
|
|
|
|
#endif
|
|
|
|
|
2012-10-01 01:12:36 +08:00
|
|
|
#ifndef current_pt_regs
|
|
|
|
#define current_pt_regs() task_pt_regs(current)
|
|
|
|
#endif
|
|
|
|
|
2012-11-06 01:59:15 +08:00
|
|
|
#ifndef ptrace_signal_deliver
|
2012-11-06 02:06:22 +08:00
|
|
|
#define ptrace_signal_deliver() ((void)0)
|
2012-11-06 01:59:15 +08:00
|
|
|
#endif
|
|
|
|
|
2012-11-06 02:00:27 +08:00
|
|
|
/*
|
|
|
|
* unlike current_pt_regs(), this one is equal to task_pt_regs(current)
|
|
|
|
* on *all* architectures; the only reason to have a per-arch definition
|
|
|
|
* is optimisation.
|
|
|
|
*/
|
|
|
|
#ifndef signal_pt_regs
|
|
|
|
#define signal_pt_regs() task_pt_regs(current)
|
|
|
|
#endif
|
|
|
|
|
2012-11-19 01:50:10 +08:00
|
|
|
#ifndef current_user_stack_pointer
|
|
|
|
#define current_user_stack_pointer() user_stack_pointer(current_pt_regs())
|
|
|
|
#endif
|
|
|
|
|
2008-07-26 10:45:59 +08:00
|
|
|
extern int task_current_syscall(struct task_struct *target, long *callno,
|
|
|
|
unsigned long args[6], unsigned int maxargs,
|
|
|
|
unsigned long *sp, unsigned long *pc);
|
|
|
|
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|