The following patch adds a new functionality to ptrace:
system call notification to the current process.

It applies to the 2.6.26 vanilla kernel for the x86 and s390 architectures.

It provides the following:
---------------------------------
   - Activation and de-activation of the functionality through ptrace
     system call
   - When the functionality is activated, the system call is not done
     and the calling process receives a SIGSYS signal.

What is it good for?
--------------------------
   - Debugging : a tracing tool can be implemented inside the space
     of the current thread and access the thread data directly from
     inside reducing task switch and IPC overhead.
   - Virtualization : a system call interposition mechanism can be
     implemneted inside the space of the current thread reducing the
     overhead of task switch and IPC and access directly all syscall
     parameters

What is missing?
----------------------
   - Port to other architectures.

It follows the patch itself.

-- 
=============
Pierre Morel
RTOS and Embedded Linux

[ message continues ]

The indenting here looks messed up.

Also, there looks to be a pretty substantial amount of copy-and-paste
code in those little if()s.  It's only going to get worse as we add more
architectures.  If there's ever a little buglet in that bit of code, or
we need to tweak it it some way, it'll be a bitch to fix.

For instance, if you have a little arch-independent helper like this:

static inline int is_self_ptracing(unsigned long syscall_reg)
{
	if (!(current->ptrace & PT_SELF))
		return 0;
	if (syscall_reg == __NR_rt_sigreturn)
		return 0;
	if (syscall_reg == __NR_ptrace)
		return 0;
	return 1;
}

You can call it like this:

	if (is_self_ptracing(regs->gprs[2]))
...
	if (is_self_ptracing(regs->orig_ax))
...
	if (is_self_ptracing(regs->orig_rax))

Something similar can probably be done for the siginfo construction.

You should basically try and think of ways to abstract this stuff every
single time you touch arch code.  

Why don't you also mention why you really want this feature.  That's
missing from the description. 

-- Dave

--

[ message continues ]

Hi,

You are right, I will rework the patch and send it again, it has a lot of
Thanks for the comments, I rework the patch.

Pierre

-- 
=============
Pierre Morel
RTOS and Embedded Linux

--

[ message continues ]

I didn't read the whole patch, but this sets PT_SELF without PT_PTRACED
(and without ptrace_attach).

We have some "->ptrace != 0" checks which can misunderstand this. Just
for example, suppose that the task does sys_ptrace(PTRACE_SELF_ON) and
then its parent dies. I guess in that case forget_original_parent()
will hit BUG_ON(p->ptrace), no?

Oleg.

--

[ message continues ]

Hello Oleg,

Yes it is the way it is intended to work.
PT_SELF and other ptrace requests are not correlated,
I use the ptrace infrastructure to take advantage
Yes you are right, I will take care of those cases.
I have the choice between:

- tracking all references to the ptrace flags and add a test for PT_SELF
or a mask.

- add a dedicated task_struct entry to hold the PT_SELF flag

The second solution seems easier, simpler and more
readable but extends the task struct.

Thanks,

Pierre




-- 
=============
Pierre Morel
RTOS and Embedded Linux

--

[ message continues ]

Well, given that PT_SELF is exotic, neither choice looks very good, imho.
But I am not expert and maintainer is cc'ed ;)

I don't understand why this patch changes the x86's sys_sigaction().
On s390 the patch changes handle_signal(), this is not clear to me too.
do_syscall_trace() filters out __NR_ptrace, this afaics means that the
handler for SIGSYS can happily call sys_ptrace(PTRACE_SELF_OFF) and
clear PT_SELF/TIF_SYSCALL_TRACE.

I must admit, personally I don't think the whole idea is good...
And what if the user of PT_SELF is ptraced? The usage of TIF_SYSCALL_TRACE
doesn't look "safe" in that case.


Isn't it possible to implement this behaviour in the user space? If the
task needs the PT_SELF behaviour, it can fork another process which will
do PTRACE_ATTACH and then send the notifications to the task. We can use
signals or something else.

Oleg.

--

[ message continues ]

Me neither, it should be only in handle_signal(), sorry it is a bug.
I am reworking the patch to take your remarks and the remarks
The patch clears the trace flags before delivering the signal so
Yes.
The situation is the following: the ptrace_self implementation is not
compatible with the standard ptrace.
In fact it is a new tracing system using the infrastructure of
ptrace because it exist but it could leave completely separate from
Yes, I will had exclusive access to the tracing so that one can not
In this case we would go back to standard ptrace behaviour.
The goal of the patch is to avoid the overhead of task switching
thanks,

Pierre

-- 
=============
Pierre Morel
RTOS and Embedded Linux

--

[ message continues ]

Yes I see. But the signal handler for SIGSYS can fisrt do
sys_ptrace(PTRACE_SELF_OFF) (which is filtered out), and then use any
other syscall.

With this patch PT_SELF is cleared on any signal. This doesn't look
right. Let's suppose that another signal comes in parallel with SIGSYS.
It is very possible that the handler for that another signal will be

Ah, I forgot to read the changelog, sorry.

Oleg.

--

[ message continues ]

If the tracing application catches all signals before delivering
them to the instrumented original handler there is no problem,
the catching code can reset PTRACE_SELF_ON before calling the 
instrumented application's original handler.
The instrumented code will then bounce as expected.

I see this more like a security, the "bouncing" feature
is only enabled until next syscall or signal, never more.

This instrumentation method allows with this little patch to do
all the syscall and signal instrumentation in userland and inside the
address space of the instrumented application.

I expect we will  have a big improvement of instrumenting tools like
 - debugger, tracing tool,
 - virtualization applications like UML
 - High availability: checkpoint and restart, record and replay.
because of the reduction of IPC and task switch overhead.

Pierre

-- 
=============
Pierre Morel
RTOS and Embedded Linux

--

[ message continues ]

Sorry, can't understand the text above :(

OK, let's suppose the application does

	ptrace(PTRACE_SELF_ON);
	...
	syscall();

This "syscall()" above should trigger the handler for SIGSYS.
But what if another signal (with handler) comes in between?
In that case handle_signal() clears PT_SELF/TIF_SYSCALL_TRACE,
this syscall() (or any other) doesn't send SIGSYS.

Oleg.

--

[ message continues ]

May be, but very high compared to the operation to just
clear a flag in the task struct.
ok, please read "set PTRACE_SELF_ON"
where I wrote "reset PTRACE_SELF_ON" above.

Now, suppose the application does the following:

sigsys_handler(sig)
{
....
ptrace(PTRACE_SELF_ON);
}

sigx_handler(sig)
{
....
ptrace(PTRACE_SELF_ON);
if (sig_has_a_handler)
call_the_handler()
ptrace(PTRACE_SELF_OFF);
...
ptrace(PTRACE_SELF_ON);
}

main(){
...
signal(SIGSYS, sigsys_handler);
for(i=0; i<MAXSIGS; i++)
signal(i, sigx_handler);
ptrace(PTRACE_SELF_ON);
jump_into_instrumented_code;
...
}

If the instrumented code ever does a call to
signal(2), the call will be received by sig_sys() handler,
where the call the application signal handler can be performed with
PTRACE_SELF_ON.
This implies appropriate instrumentation of signal(2) and sigaction(2).

Pierre

-- 
=============
Pierre Morel
RTOS and Embedded Linux

--

[ message continues ]