* Re: [PATCH 1/1] system call notification with self_ptrace
2008-09-09 0:04 ` [PATCH 1/1] system call notification with self_ptrace Andrew Morton
@ 2008-09-10 14:17 ` Pierre Morel
0 siblings, 0 replies; 2+ messages in thread
From: Pierre Morel @ 2008-09-10 14:17 UTC (permalink / raw)
To: Andrew Morton
Cc: linux-kernel, oleg, roland, heicars2, sameske, schwidefsky, mingo,
gregkh, user-mode-linux-devel, dave, clg, dlezcano,
Michael Kerrisk, linux-arch
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
^ permalink raw reply [flat|nested] 2+ messages in thread