From: Denys Vlasenko <vda.linux@googlemail.com>
To: Oleg Nesterov <oleg@redhat.com>
Cc: Tejun Heo <tj@kernel.org>,
linux-kernel@vger.kernel.org,
Denys Vlasenko <vda.linux@googlemail.com>,
dvlasenk@redhat.com
Subject: [PATCH v2] Make PTRACE_SEIZE set ptrace options specified in 'data' parameter
Date: Wed, 7 Sep 2011 23:40:31 +0200 [thread overview]
Message-ID: <201109072340.31460.vda.linux@googlemail.com> (raw)
Make PTRACE_SEIZE set ptrace options specified in 'data' parameter
This can be used to close a few corner cases in strace where we get
unwanted racy behavior after attach, but before we have a chance
to set options (the notorious post-execve SIGTRAP comes to mind),
and removes the need to track "did we set opts for this task" state
in strace internals.
While we are at it:
Make it possible to extend SEIZE in the future with more functionality
by passing non-zero 'addr' parameter.
To that end, error out if 'addr' is non-zero.
PTRACE_ATTACH did not (and still does not) have such check,
and users (strace) do pass garbage there... let's avoid repeating
this mistake with SEIZE.
Set all task->ptrace bits in one operation - before this change,
we were adding PT_SEIZED and PT_PTRACE_CAP with task->ptrace |= BIT.
This was probably ok (not a bug), but let's be on a safer side.
Signed-off-by: Denys Vlasenko <dvlasenk@redhat.com>
diff --git a/kernel/ptrace.c b/kernel/ptrace.c
index 0316200..43aa09c 100644
--- a/kernel/ptrace.c
+++ b/kernel/ptrace.c
@@ -212,6 +212,7 @@ bool ptrace_may_access(struct task_struct *task, unsigned int mode)
}
static int ptrace_attach(struct task_struct *task, long request,
+ unsigned long addr,
unsigned long flags)
{
bool seize = (request == PTRACE_SEIZE);
@@ -219,19 +220,27 @@ static int ptrace_attach(struct task_struct *task, long request,
/*
* SEIZE will enable new ptrace behaviors which will be implemented
- * gradually. SEIZE_DEVEL is used to prevent applications
+ * gradually. SEIZE_DEVEL bit is used to prevent applications
* expecting full SEIZE behaviors trapping on kernel commits which
* are still in the process of implementing them.
*
* Only test programs for new ptrace behaviors being implemented
* should set SEIZE_DEVEL. If unset, SEIZE will fail with -EIO.
*
- * Once SEIZE behaviors are completely implemented, this flag and
- * the following test will be removed.
+ * Once SEIZE behaviors are completely implemented, this flag
+ * will be removed.
*/
retval = -EIO;
- if (seize && !(flags & PTRACE_SEIZE_DEVEL))
- goto out;
+ if (seize) {
+ if (addr != 0)
+ goto out;
+ if ((flags & ~(long)PTRACE_O_MASK) != PTRACE_SEIZE_DEVEL)
+ goto out;
+ flags &= ~PTRACE_SEIZE_DEVEL;
+ flags = PT_PTRACED | PT_SEIZED | (flags << PT_OPT_FLAG_SHIFT);
+ } else {
+ flags = PT_PTRACED;
+ }
audit_ptrace(task);
@@ -263,11 +272,9 @@ static int ptrace_attach(struct task_struct *task, long request,
if (task->ptrace)
goto unlock_tasklist;
- task->ptrace = PT_PTRACED;
- if (seize)
- task->ptrace |= PT_SEIZED;
if (task_ns_capable(task, CAP_SYS_PTRACE))
- task->ptrace |= PT_PTRACE_CAP;
+ flags |= PT_PTRACE_CAP;
+ task->ptrace = flags;
__ptrace_link(task, current);
@@ -865,7 +872,7 @@ SYSCALL_DEFINE4(ptrace, long, request, long, pid, unsigned long, addr,
}
if (request == PTRACE_ATTACH || request == PTRACE_SEIZE) {
- ret = ptrace_attach(child, request, data);
+ ret = ptrace_attach(child, request, addr, data);
/*
* Some architectures need to do book-keeping after
* a ptrace attach.
next reply other threads:[~2011-09-07 21:40 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-09-07 21:40 Denys Vlasenko [this message]
2011-09-07 23:55 ` [PATCH v2] Make PTRACE_SEIZE set ptrace options specified in 'data' parameter Pedro Alves
2011-09-08 0:44 ` Tejun Heo
2011-09-08 18:17 ` Oleg Nesterov
2011-09-11 2:05 ` Tejun Heo
2011-09-11 18:14 ` Oleg Nesterov
2011-09-13 8:00 ` Tejun Heo
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=201109072340.31460.vda.linux@googlemail.com \
--to=vda.linux@googlemail.com \
--cc=dvlasenk@redhat.com \
--cc=linux-kernel@vger.kernel.org \
--cc=oleg@redhat.com \
--cc=tj@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).