Messages in this thread | | | From | Pedro Alves <> | Subject | Re: [PATCH v3] Make PTRACE_SEIZE set ptrace options specified in 'data' | Date | Sat, 10 Sep 2011 16:36:36 +0100 |
| |
On Saturday 10 September 2011 13:12:38, Pedro Alves wrote:
> (just-options-on-SEIZE scares me in terms of future expansion, > as it assumes only bitflags will ever be necessary.)
The more I think of this, the more I think we could do this some other way --- why don't we allow setting the default options _on the ptracer_, and then tracee's inherit those options from the ptracer-set-of-default-options if their parent is not currently ptraced by own tracer? That is, you'd make the ptracer set options on itself:
options = PTRACE_O_TRACESYSGOOD | PTRACE_O_TRACECLONE|FORK|VFORK|EXEC ...; ptrace(PTRACE_SETOPTIONS, gettid(), 0, options);
And then, in all of
ptrace(PTRACE_ATTACH, foo_pid, 0, 0); ptrace(PTRACE_TRACEME, 0, 0, 0); ptrace(PTRACE_SEIZE, foo_pid, 0, 0);
you'd end up with the tracee already with your chosen options set.
Clones, vforks and forks that are auto-attached would still inherit their options from their parent, just like today.
Some pro points:
- works for PTRACE_ATTACH AND PTRACE_TRACEME too.
- most ptracers on earth will only need to set options once.
- backwards compatible. The "default ptrace options" default to 0, so old tracers on new kernels will still behave the same.
- future proof. If some other PTRACE_SET_NEAT_OPTION ptrace command appears in the future, we can make it work the same way, instead of getting stuck with PTRACE_SEIZE's `data' already being taken...
- if ptrace(PTRACE_SETOPTIONS, gettid(), 0, 0) works, then we can stop gdb (and probably other tracers) from forking a new child just to check if PTRACE_O_TRACEFOO works before actually attaching/spawning the process of interest. (see code around linux_supports_tracefork_flag at <http://sourceware.org/cgi-bin/cvsweb.cgi/src/gdb/linux-nat.c?rev=1.215&content-type=text/x-cvsweb-markup&cvsroot=src>)
Cons:
- is there any real con?
Note the default ptrace options would _not_ conflict with the ptracer's own ptrace options in case the ptracer itself is being ptraced.
WDYT?
-- Pedro Alves
| |