License cleanup: add SPDX GPL-2.0 license identifier to files with no license
Many source files in the tree are missing licensing information, which
makes it harder for compliance tools to determine the correct license.
By default all files without license information are under the default
license of the kernel, which is GPL version 2.
Update the files which contain no license information with the 'GPL-2.0'
SPDX license identifier. The SPDX identifier is a legally binding
shorthand, which can be used instead of the full boiler plate text.
This patch is based on work done by Thomas Gleixner and Kate Stewart and
Philippe Ombredanne.
How this work was done:
Patches were generated and checked against linux-4.14-rc6 for a subset of
the use cases:
- file had no licensing information it it.
- file was a */uapi/* one with no licensing information in it,
- file was a */uapi/* one with existing licensing information,
Further patches will be generated in subsequent months to fix up cases
where non-standard license headers were used, and references to license
had to be inferred by heuristics based on keywords.
The analysis to determine which SPDX License Identifier to be applied to
a file was done in a spreadsheet of side by side results from of the
output of two independent scanners (ScanCode & Windriver) producing SPDX
tag:value files created by Philippe Ombredanne. Philippe prepared the
base worksheet, and did an initial spot review of a few 1000 files.
The 4.13 kernel was the starting point of the analysis with 60,537 files
assessed. Kate Stewart did a file by file comparison of the scanner
results in the spreadsheet to determine which SPDX license identifier(s)
to be applied to the file. She confirmed any determination that was not
immediately clear with lawyers working with the Linux Foundation.
Criteria used to select files for SPDX license identifier tagging was:
- Files considered eligible had to be source code files.
- Make and config files were included as candidates if they contained >5
lines of source
- File already had some variant of a license header in it (even if <5
lines).
All documentation files were explicitly excluded.
The following heuristics were used to determine which SPDX license
identifiers to apply.
- when both scanners couldn't find any license traces, file was
considered to have no license information in it, and the top level
COPYING file license applied.
For non */uapi/* files that summary was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 11139
and resulted in the first patch in this series.
If that file was a */uapi/* path one, it was "GPL-2.0 WITH
Linux-syscall-note" otherwise it was "GPL-2.0". Results of that was:
SPDX license identifier # files
---------------------------------------------------|-------
GPL-2.0 WITH Linux-syscall-note 930
and resulted in the second patch in this series.
- if a file had some form of licensing information in it, and was one
of the */uapi/* ones, it was denoted with the Linux-syscall-note if
any GPL family license was found in the file or had no licensing in
it (per prior point). Results summary:
SPDX license identifier # files
---------------------------------------------------|------
GPL-2.0 WITH Linux-syscall-note 270
GPL-2.0+ WITH Linux-syscall-note 169
((GPL-2.0 WITH Linux-syscall-note) OR BSD-2-Clause) 21
((GPL-2.0 WITH Linux-syscall-note) OR BSD-3-Clause) 17
LGPL-2.1+ WITH Linux-syscall-note 15
GPL-1.0+ WITH Linux-syscall-note 14
((GPL-2.0+ WITH Linux-syscall-note) OR BSD-3-Clause) 5
LGPL-2.0+ WITH Linux-syscall-note 4
LGPL-2.1 WITH Linux-syscall-note 3
((GPL-2.0 WITH Linux-syscall-note) OR MIT) 3
((GPL-2.0 WITH Linux-syscall-note) AND MIT) 1
and that resulted in the third patch in this series.
- when the two scanners agreed on the detected license(s), that became
the concluded license(s).
- when there was disagreement between the two scanners (one detected a
license but the other didn't, or they both detected different
licenses) a manual inspection of the file occurred.
- In most cases a manual inspection of the information in the file
resulted in a clear resolution of the license that should apply (and
which scanner probably needed to revisit its heuristics).
- When it was not immediately clear, the license identifier was
confirmed with lawyers working with the Linux Foundation.
- If there was any question as to the appropriate license identifier,
the file was flagged for further research and to be revisited later
in time.
In total, over 70 hours of logged manual review was done on the
spreadsheet to determine the SPDX license identifiers to apply to the
source files by Kate, Philippe, Thomas and, in some cases, confirmation
by lawyers working with the Linux Foundation.
Kate also obtained a third independent scan of the 4.13 code base from
FOSSology, and compared selected files where the other two scanners
disagreed against that SPDX file, to see if there was new insights. The
Windriver scanner is based on an older version of FOSSology in part, so
they are related.
Thomas did random spot checks in about 500 files from the spreadsheets
for the uapi headers and agreed with SPDX license identifier in the
files he inspected. For the non-uapi files Thomas did random spot checks
in about 15000 files.
In initial set of patches against 4.14-rc6, 3 files were found to have
copy/paste license identifier errors, and have been fixed to reflect the
correct identifier.
Additionally Philippe spent 10 hours this week doing a detailed manual
inspection and review of the 12,461 patched files from the initial patch
version early this week with:
- a full scancode scan run, collecting the matched texts, detected
license ids and scores
- reviewing anything where there was a license detected (about 500+
files) to ensure that the applied SPDX license was correct
- reviewing anything where there was no detection but the patch license
was not GPL-2.0 WITH Linux-syscall-note to ensure that the applied
SPDX license was correct
This produced a worksheet with 20 files needing minor correction. This
worksheet was then exported into 3 different .csv files for the
different types of files to be modified.
These .csv files were then reviewed by Greg. Thomas wrote a script to
parse the csv files and add the proper SPDX tag to the file, in the
format that the file expected. This script was further refined by Greg
based on the output to detect more types of files automatically and to
distinguish between header and source .c files (which need different
comment types.) Finally Greg ran the script using the .csv files to
generate the patches.
Reviewed-by: Kate Stewart <kstewart@linuxfoundation.org>
Reviewed-by: Philippe Ombredanne <pombredanne@nexb.com>
Reviewed-by: Thomas Gleixner <tglx@linutronix.de>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
2017-11-01 22:07:57 +08:00
|
|
|
/* SPDX-License-Identifier: GPL-2.0 */
|
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>
|
2016-11-08 05:26:35 +08:00
|
|
|
#include <linux/seccomp.h>
|
|
|
|
|
|
|
|
/* Add sp to seccomp_data, as seccomp is user API, we don't want to modify it */
|
|
|
|
struct syscall_info {
|
|
|
|
__u64 sp;
|
|
|
|
struct seccomp_data data;
|
|
|
|
};
|
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
|
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
|
|
|
|
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);
|
2022-01-28 02:19:13 +08:00
|
|
|
extern int ptrace_notify(int exit_code, unsigned long message);
|
2005-04-17 06:20:36 +08:00
|
|
|
extern void __ptrace_link(struct task_struct *child,
|
2017-05-23 04:40:12 +08:00
|
|
|
struct task_struct *new_parent,
|
|
|
|
const struct cred *ptracer_cred);
|
2005-04-17 06:20:36 +08:00
|
|
|
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
|
2018-09-25 20:38:18 +08:00
|
|
|
#define PTRACE_MODE_FSCREDS 0x08
|
|
|
|
#define PTRACE_MODE_REALCREDS 0x10
|
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
|
|
|
|
|
|
|
/* 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))) {
|
2022-01-28 02:15:32 +08:00
|
|
|
ptrace_notify((event << 8) | SIGTRAP, message);
|
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
|
2021-02-26 09:20:56 +08:00
|
|
|
* ptrace parent's pid namespace.
|
2014-06-07 05:36:42 +08:00
|
|
|
*
|
|
|
|
* 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;
|
2017-05-23 04:40:12 +08:00
|
|
|
__ptrace_link(child, current->parent, current->ptracer_cred);
|
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);
|
2008-07-26 10:45:47 +08:00
|
|
|
}
|
2017-05-23 04:40:12 +08:00
|
|
|
else
|
|
|
|
child->ptracer_cred = NULL;
|
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 */
|
|
|
|
|
2018-04-17 03:18:26 +08:00
|
|
|
#ifdef ARCH_HAS_USER_SINGLE_STEP_REPORT
|
|
|
|
extern void user_single_step_report(struct pt_regs *regs);
|
2009-12-16 08:47:17 +08:00
|
|
|
#else
|
2018-04-17 03:18:26 +08:00
|
|
|
static inline void user_single_step_report(struct pt_regs *regs)
|
2009-12-16 08:47:17 +08:00
|
|
|
{
|
2018-09-25 17:27:20 +08:00
|
|
|
kernel_siginfo_t info;
|
2018-04-17 03:18:26 +08:00
|
|
|
clear_siginfo(&info);
|
|
|
|
info.si_signo = SIGTRAP;
|
|
|
|
info.si_errno = 0;
|
|
|
|
info.si_code = SI_USER;
|
|
|
|
info.si_pid = 0;
|
|
|
|
info.si_uid = 0;
|
2019-05-15 23:11:09 +08:00
|
|
|
force_sig_info(&info);
|
2009-12-16 08:47:17 +08:00
|
|
|
}
|
|
|
|
#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
|
|
|
|
*
|
|
|
|
* This is called with the siglock held, to decide whether or not it's
|
2021-09-03 05:10:11 +08:00
|
|
|
* necessary to release the siglock and call arch_ptrace_stop(). 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
|
|
|
*/
|
2021-09-03 05:10:11 +08:00
|
|
|
#define arch_ptrace_stop_needed() (0)
|
2008-02-06 17:37:37 +08:00
|
|
|
#endif
|
|
|
|
|
|
|
|
#ifndef arch_ptrace_stop
|
|
|
|
/**
|
|
|
|
* arch_ptrace_stop - Do machine-specific work before stopping for ptrace
|
|
|
|
*
|
|
|
|
* 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().
|
|
|
|
*/
|
2021-09-03 05:10:11 +08:00
|
|
|
#define arch_ptrace_stop() do { } while (0)
|
2008-02-06 17:37:37 +08:00
|
|
|
#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 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
|
|
|
|
|
2016-11-08 05:26:35 +08:00
|
|
|
extern int task_current_syscall(struct task_struct *target, struct syscall_info *info);
|
2008-07-26 10:45:59 +08:00
|
|
|
|
2018-11-22 10:04:09 +08:00
|
|
|
extern void sigaction_compat_abi(struct k_sigaction *act, struct k_sigaction *oact);
|
2022-01-28 01:17:32 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* ptrace report for syscall entry and exit looks identical.
|
|
|
|
*/
|
|
|
|
static inline int ptrace_report_syscall(unsigned long message)
|
|
|
|
{
|
|
|
|
int ptrace = current->ptrace;
|
2022-01-28 02:19:13 +08:00
|
|
|
int signr;
|
2022-01-28 01:17:32 +08:00
|
|
|
|
|
|
|
if (!(ptrace & PT_PTRACED))
|
|
|
|
return 0;
|
|
|
|
|
2022-01-28 02:19:13 +08:00
|
|
|
signr = ptrace_notify(SIGTRAP | ((ptrace & PT_TRACESYSGOOD) ? 0x80 : 0),
|
|
|
|
message);
|
2022-01-28 01:17:32 +08:00
|
|
|
|
|
|
|
/*
|
|
|
|
* this isn't the same as continuing with a signal, but it will do
|
|
|
|
* for normal use. strace only continues with a signal if the
|
|
|
|
* stopping signal is not SIGTRAP. -brl
|
|
|
|
*/
|
2022-01-28 02:19:13 +08:00
|
|
|
if (signr)
|
|
|
|
send_sig(signr, current, 1);
|
2022-01-28 01:17:32 +08:00
|
|
|
|
|
|
|
return fatal_signal_pending(current);
|
|
|
|
}
|
2022-01-28 01:46:37 +08:00
|
|
|
|
|
|
|
/**
|
|
|
|
* ptrace_report_syscall_entry - task is about to attempt a system call
|
|
|
|
* @regs: user register state of current task
|
|
|
|
*
|
|
|
|
* This will be called if %SYSCALL_WORK_SYSCALL_TRACE or
|
|
|
|
* %SYSCALL_WORK_SYSCALL_EMU have been set, when the current task has just
|
|
|
|
* entered the kernel for a system call. Full user register state is
|
|
|
|
* available here. Changing the values in @regs can affect the system
|
|
|
|
* call number and arguments to be tried. It is safe to block here,
|
|
|
|
* preventing the system call from beginning.
|
|
|
|
*
|
|
|
|
* Returns zero normally, or nonzero if the calling arch code should abort
|
|
|
|
* the system call. That must prevent normal entry so no system call is
|
|
|
|
* made. If @task ever returns to user mode after this, its register state
|
|
|
|
* is unspecified, but should be something harmless like an %ENOSYS error
|
|
|
|
* return. It should preserve enough information so that syscall_rollback()
|
|
|
|
* can work (see asm-generic/syscall.h).
|
|
|
|
*
|
|
|
|
* Called without locks, just after entering kernel mode.
|
|
|
|
*/
|
|
|
|
static inline __must_check int ptrace_report_syscall_entry(
|
|
|
|
struct pt_regs *regs)
|
|
|
|
{
|
|
|
|
return ptrace_report_syscall(PTRACE_EVENTMSG_SYSCALL_ENTRY);
|
|
|
|
}
|
|
|
|
|
|
|
|
/**
|
|
|
|
* ptrace_report_syscall_exit - task has just finished a system call
|
|
|
|
* @regs: user register state of current task
|
|
|
|
* @step: nonzero if simulating single-step or block-step
|
|
|
|
*
|
|
|
|
* This will be called if %SYSCALL_WORK_SYSCALL_TRACE has been set, when
|
|
|
|
* the current task has just finished an attempted system call. Full
|
|
|
|
* user register state is available here. It is safe to block here,
|
|
|
|
* preventing signals from being processed.
|
|
|
|
*
|
|
|
|
* If @step is nonzero, this report is also in lieu of the normal
|
|
|
|
* trap that would follow the system call instruction because
|
|
|
|
* user_enable_block_step() or user_enable_single_step() was used.
|
|
|
|
* In this case, %SYSCALL_WORK_SYSCALL_TRACE might not be set.
|
|
|
|
*
|
|
|
|
* Called without locks, just before checking for pending signals.
|
|
|
|
*/
|
|
|
|
static inline void ptrace_report_syscall_exit(struct pt_regs *regs, int step)
|
|
|
|
{
|
|
|
|
if (step)
|
|
|
|
user_single_step_report(regs);
|
|
|
|
else
|
|
|
|
ptrace_report_syscall(PTRACE_EVENTMSG_SYSCALL_EXIT);
|
|
|
|
}
|
2005-04-17 06:20:36 +08:00
|
|
|
#endif
|