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] [day] [month] [year] [list]

Date:	Thu, 14 Jun 2012 23:57:41 -0400
From:	Filipe Brandenburger <filbranden@...il.com>
To:	Albert Cahalan <acahalan@...il.com>,
	David Wilcox <davidvsthegiant@...il.com>,
	"Adam H. Peterson" <AlphaEtaPi@...mail.com>
Cc:	Oleg Nesterov <oleg@...hat.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

Hi,

On Wed, Jun 13, 2012 at 11:46 AM, Albert Cahalan <acahalan@...il.com> wrote:
>> On 06/11, Filipe Brandenburger wrote:
>>> 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.

The issue I have with the current implementation is that it's non
obvious, it has some quite awkward corner cases (see
https://bugzilla.kernel.org/show_bug.cgi?id=43300) and it ends up
exposing implementation details of the Linux kernel that should not
really be that visible to userland...

But I don't really have a strong case for needing this change, I only
got involved on it through the Bugzilla report, it struck me as odd...

I'm copying David Wilcox who opened the Bugzilla issue and Adam
Peterson who commented on the issue, they both seem to have use cases
for the code to match the documentation, they might be able to give
better arguments of why they would like to have this behavior changed.

Thanks,
Filipe
--
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/