Messages in this thread | | | Date | Wed, 10 Sep 2008 16:17:31 +0200 | From | Pierre Morel <> | Subject | Re: [PATCH 1/1] system call notification with self_ptrace |
| |
Hi,
Andrew Morton wrote: > On Mon, 08 Sep 2008 14:02:01 +0200 > Pierre Morel <pmorel@linux.vnet.ibm.com> wrote: > > >> Subject: [PATCH] system call notification with self_ptrace >> >> From: Pierre Morel <pmorel@fr.ibm.com> >> >> >> PTRACE SELF >> >> This patch adds a new functionality to ptrace: system call notification to >> the current process. >> When a process requests self ptrace, with the new request PTRACE_SELF_ON: >> >> 1. the next system call performed by the process will not be executed >> 2. self ptrace will be disabled for the process >> 3. a SIGSYS signal will be sent to the process. >> >> With an appropriate SIGSYS signal handler, the process can access its own >> data structures to >> >> 1. get the system call number from the siginfo structure >> 2. get the system call arguments from the stack >> 3. instrument the system call with other system calls >> 4. emulate the system call with other system calls >> 5. change the arguments of the system call >> 6. perform the system call for good >> 7. change the return value of the system call >> 8. request self ptrace again before returning. >> >> The new request PTRACE_SELF_OFF disables self ptrace. >> >> > > It sounds like it might be useful. > Thanks, yes I am sure it might. > Are there any userspace tools available with which people can utilise > this new functionality? Or plans to release them? > Yes, we plan to release a tool to trace an application soon. > >> arch/s390/kernel/ptrace.c | 16 ++++++++++++++++ >> arch/s390/kernel/signal.c | 5 +++++ >> arch/x86/kernel/ptrace.c | 29 +++++++++++++++++++++++++++++ >> arch/x86/kernel/signal_32.c | 5 +++++ >> arch/x86/kernel/signal_64.c | 5 +++++ >> > > Maintainers of the other 30-odd architectures would appreciate a test > application which they can use to develop and test their ports, please. > Yes, of course I have one for x86 and one for s390. I am cleaning them to make them available. > Michael Kerrisk will no doubt be looking for manpage assistance. > Please cc him on this material. > OK, I will prepare this. > It would be good to get suitable testcases integrated into LTP (if LTP > has ptrace tests). > Yes, I will prepare this too. > The patch title uses the term "self_ptrace", but the patch itself uses > the term "ptrace_self". Let's get it consistent everywhere. > Right. It should be self_ptrace. > The patch adds a > > + u64 instrumentation; > > to the task_struct but no explanation is provided as to why this was > added, why it is a 64-bit field, what its locking rules are, etc. > Please fix this. >
I used to steal one bit in the ptrace bit-field of the task_struct but Oleg pointed out that the ptrace bit-field is used in a lot of places without any bit mask, so I chose another way to remember that I (the thread) am instrumenting myself.
Alternatively, I could also use the ptrace bit-field and modify every reference to use a mask for any test, set or reset of the bit-field.
I provision a 64 bit wide bit-field for future extensions of the instrumentation. I could of course use a smaller bit-field as only 1 bit is really useful for now. I used 64 bit to be memory aligned with most of the architectures.
There is no lock for the instrumentation bit-field because it is used for self tracing only, and only current ever accesses the flag.
-- ============= Pierre Morel RTOS and Embedded Linux
| |