linux-kernel - Re: [PATCH] change kernel threads to ignore signals instead of blocking them

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 Apr 2007 08:13:32 -0600
From:	ebiederm@...ssion.com (Eric W. Biederman)
To:	Oleg Nesterov <oleg@...sign.ru>
Cc:	Andrew Morton <akpm@...ux-foundation.org>,
	Davide Libenzi <davidel@...ilserver.org>,
	Ingo Molnar <mingo@...e.hu>,
	Roland McGrath <roland@...hat.com>,
	linux-kernel@...r.kernel.org
Subject: Re: [PATCH] change kernel threads to ignore signals instead of blocking them

Oleg Nesterov <oleg@...sign.ru> writes:

> On top of Eric's
>
> 	kthread-dont-depend-on-work-queues-take-2.patch
>
> Currently kernel threads use sigprocmask(SIG_BLOCK) to protect against signals.
> This doesn't prevent the signal delivery, this only blocks signal_wake_up().
> Every "killall -33 kthreadd" means a "struct siginfo" leak.
>
> Change kthreadd_setup() to set all handlers to SIG_IGN instead of blocking them
> (make a new helper ignore_signals() for that). If the kernel thread needs some
> signal, it should use allow_signal() anyway, and in that case it should not use
> CLONE_SIGHAND.
>
> Note that we can't change daemonize() (should die!) in the same way, because
> it can be used along with CLONE_SIGHAND. This means that allow_signal() still
> should unblock the signal to work correctly with daemonize()ed threads.
>
> However, disallow_signal() doesn't block the signal any longer but ignores it.
>
> NOTE: with or without this patch the kernel threads are not protected from
> handle_stop_signal(), this seems harmless, but not good.

Hmm.  I like it all except for disallow_signal.

disallow_signal currently only has one user, jffs2.  While jffs2
currently doesn't care, given the way jffs2 is using disallow_signal I
would expect it would prefer to have the signal blocked.

Thinking about this some more if jffs2 or anyone else wants blocked
signal behavior they can go ahead and block the signal.  Keeping
disallow_signal in sync with allow_signal seems to make sense.

Nothing in the kernel should break with this change so:

Acked-by: "Eric W. Biederman" <ebiederm@...ssion.com>
-
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/