linux-kernel - Re: [RFC][PATCH 11/11] signal: Ignore all but multi-process signals that come in during fork.

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:   Fri, 13 Jul 2018 09:51:28 -0500
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     Oleg Nesterov <oleg@...hat.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Andrew Morton <akpm@...ux-foundation.org>,
        linux-kernel@...r.kernel.org, Wen Yang <wen.yang99@....com.cn>,
        majiang <ma.jiang@....com.cn>
Subject: Re: [RFC][PATCH 11/11] signal: Ignore all but multi-process signals that come in during fork.

Oleg Nesterov <oleg@...hat.com> writes:

> That is why I tried to sugest another approach. copy_process() should always fail
> if signal_pending() == T, just the "real" signal should not disturb the forking
> thread unless the signal is fatal or multi-process.

I understand now why you are suggesting another approach.  There are lot
of cases that could be affected by the removal of
"if (signal_pending()) return restart_syscall();" in copy_process.

I just shiver at the thought of leaving the code that way.  That is just
leaving a mess for later and the signal handling code already has way
too many of those.

So I am going to try and work through all of the cases.

I might even implement queueing shared signals for after the fork.  As
it is looking increasingly less difficult.

Eric