Re: Trouble with ptrace self-attach rule since kernel > 2.6.14

[Markus Gutschke <markus@google.com>]

Oleg Nesterov wrote:
> It's a pity to disappoint you, but you may be the 3rd :) Found this
> unanswered message:
> 
> 	http://marc.theaimsgroup.com/?l=linux-kernel&m=114073955827139
> 
> (the author cc'ed)


I think, I would be the second one rather than the third one. Linus 
replied to me personally, and that is probably the reason why the 
archive shows the question as unanswered.

For the record (i.e. the mailing list archives), yes, I was able to 
change my application to use clone(CLONE_VM) followed by ptrace(), 
instead of ptrace()'ing from one of the threads in my application.

There were a few minor obstacles that I had to overcome, though. E.g. 
some versions of glibc find the location of "errno" by looking at the 
current stack pointer and masking off some bits. Since my code should be 
portable across a large range of different glibc and kernel versions, I 
had to accommodate this behavior by either 1) allocating the new 
thread's stack within the old thread's stack, effectively sharing 
"errno", or 2) making direct system calls and avoiding all functions 
that access "errno".

The former approach is preferable when using CLONE_VFORK, but if that is 
not an option than the second approach will work OK.

Overall, it turned out to be a few weeks worth of work making these 
changes, but (as usual) most of the time was spent validating that the 
new code works on all platforms and in all usage scenarios. As a result, 
the new code is actually better than the old one. There definitely 
seemed to be problems with the old approach and some older kernels, too.

Using clone(), makes the code slightly less portable, but all of this 
code is already pretty Linux-specific anyway.

I'd be happy to answer any questions about working around various bugs 
in historic kernel and glibc versions.


Markus