linux-kernel - Re: [PATCHv2 1/1] prctl: move pdeath_signal from task_struct to signal

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, 13 Jun 2012 11:46:51 -0400
From:	Albert Cahalan <acahalan@...il.com>
To:	Oleg Nesterov <oleg@...hat.com>
Cc:	Filipe Brandenburger <filbranden@...il.com>,
	Linus Torvalds <torvalds@...ux-foundation.org>,
	Andrew Morton <akpm@...ux-foundation.org>,
	Roland McGrath <roland@...k.frob.com>,
	linux-kernel@...r.kernel.org,
	"Eric W. Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCHv2 1/1] prctl: move pdeath_signal from task_struct to signal_struct

On Tue, Jun 12, 2012 at 12:19 PM, Oleg Nesterov <oleg@...hat.com> wrote:
> On 06/11, Filipe Brandenburger wrote:

> However. This code is very, very old. I simply do not know if we can
> change the current behaviour or not. In particular, Albert Cahalan
> didn't like this change when it was last discussed because it can
> break his application.
...
>> Documentation clearly states that PR_SET_PDEATHSIG and PR_GET_PDEATHSIG should
>> act on processes, in particular case #1 is very counter intuitive because the
>> child process should not care whether the parent is multi-threaded or not.

You are assuming that the child and parent are normal separate
applications, developed by separate people, with one just being
run by the other. That is actually the odd case AFAIK, because
why then would there be reason to care about parent death?
The more normal case IMHO is that the child and parent are
deeply aware of each other. Most likely they are the same program.

In my case I have an in-process emulator, kind of like valgrind,
that uses real threads for accuracy and performance. It makes
extra threads for monitoring and control. These extra threads
keep an eye on the app being examined; obviously none of this
would work if the death signal were not per-thread.

Fix the documentation to match reality, then add a per-process one
if there is any use for it. I don't think I've ever seen use for a
per-process death signal, so perhaps it shouldn't be added even
though it does make sense.
--
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/