linux-kernel - Re: Trouble with ptrace self-attach rule since kernel

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:	Mon, 04 Sep 2006 13:07:35 -0700
From:	Markus Gutschke <markus@...gle.com>
To:	Oleg Nesterov <oleg@...sign.ru>
CC:	Andreas Hobein <ah2@...air.de>, Linus Torvalds <torvalds@...l.org>,
	Andrew Morton <akpm@...l.org>,
	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Roland McGrath <roland@...hat.com>
Subject: Re: Trouble with ptrace self-attach rule since kernel > 2.6.14

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