Re: [PATCH 1/1] system call notification with self_ptrace

Re: [PATCH 1/1] system call notification with self_ptrace

[Andrew Morton]

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.

Are there any userspace tools available with which people can utilise
this new functionality?  Or plans to release them?

> 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.

Michael Kerrisk will no doubt be looking for manpage assistance. 
Please cc him on this material.

It would be good to get suitable testcases integrated into LTP (if LTP
has ptrace tests).

The patch title uses the term "self_ptrace", but the patch itself uses
the term "ptrace_self".  Let's get it consistent everywhere.

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.

Re: [PATCH 1/1] system call notification with self_ptrace

[Pierre Morel]

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