linux-kernel - Re: [PATCH] ptrace: add ability to get clear_tid

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]

Message-ID: <4F327B99.7020602@gmail.com>
Date:	Wed, 08 Feb 2012 17:41:45 +0400
From:	Andrew Vagin <avagin@...il.com>
To:	Pedro Alves <palves@...hat.com>
CC:	Oleg Nesterov <oleg@...hat.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Jan Kratochvil <jan.kratochvil@...hat.com>,
	Tejun Heo <tj@...nel.org>, Andrew Vagin <avagin@...nvz.org>,
	"linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
	Cyrill Gorcunov <gorcunov@...nvz.org>
Subject: Re: [PATCH] ptrace: add ability to get clear_tid_address

Hi All,
> Off hand, I'm not picturing a use.  But that may well just mean I'm lacking
> imagination.  Andrew, Pavel, did you have a particular idea in mind when you
> said it may be useful for debugging a multithreading program / gdb?
For example:

pthread_join() waits on a futex (child_tid_address), but a thread is 
dead already.

Where is the problem? At first I would want to check, that 
pthread_join() uses the correct address of the futex. The simple way is 
to connect to this process via gdb
and get it.

I want to say, that when you have trouble with child_tid_address, you 
may want to get it.
If the code is your, you may get it via prctl, but if it's not, what 
will you do?

Yes, we have lived without this for a long time, so I can assume that 
all what I tell is useless.

But one more reason why I want to add this in ptrace.
I want use this functionality to dump a process state.
Now we do a few actions in a context of the process which we want to 
dump. A parasite code is injected for that. This way is dangerous, 
because it may affect a target process (It may occur due to a bug in 
parasite). We use this way, because we want to add minimum functionality 
in the kernel. Our current goal is to make a full functional prototype 
and when everyone will understand that this project works and it's 
usefull, we will do improvements. And I hope in future we will save 
state of processes without parasite.

For this reason I avoid adding new actions in a parasite code, but 
prctl() can be executed only from parasite code.

If after all you are not sure that this functionality should be in 
ptrace, I will add it in prctl, it's not a problem.

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