linux-kernel - Re: [PATCH 1/1] system call notification with self

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Wed, 10 Sep 2008 16:17:31 +0200
From:	Pierre Morel <pmorel@...ux.vnet.ibm.com>
To:	Andrew Morton <akpm@...ux-foundation.org>
CC:	linux-kernel@...r.kernel.org, oleg@...sign.ru, roland@...hat.com,
	heicars2@...ux.vnet.ibm.com, sameske@...ux.vnet.ibm.com,
	schwidefsky@...ibm.com, mingo@...e.hu, gregkh@...e.de,
	user-mode-linux-devel@...ts.sourceforge.net,
	dave@...ux.vnet.ibm.com, clg@...ibm.com, dlezcano@...ibm.com,
	Michael Kerrisk <mtk.manpages@...glemail.com>,
	linux-arch@...r.kernel.org
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@...ux.vnet.ibm.com> wrote:
>
>   
>> Subject: [PATCH] system call notification with self_ptrace
>>
>> From: Pierre Morel <pmorel@...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

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/