linux-kernel - Re: [PATCH] drbd: do not ignore signals in threads

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: <ad16d006-4382-3f77-8968-6f840e58b8df@linbit.com>
Date:   Mon, 5 Aug 2019 11:33:01 +0200
From:   Christoph Böhmwalder 
        <christoph.boehmwalder@...bit.com>
To:     David Laight <David.Laight@...LAB.COM>,
        Jens Axboe <axboe@...nel.dk>
Cc:     "linux-kernel@...r.kernel.org" <linux-kernel@...r.kernel.org>,
        Philipp Reisner <philipp.reisner@...bit.com>,
        "stable@...r.kernel.org" <stable@...r.kernel.org>,
        "Eric W . Biederman" <ebiederm@...ssion.com>
Subject: Re: [PATCH] drbd: do not ignore signals in threads

On 29.07.19 10:50, David Laight wrote:
> Doesn't unmasking the signals and using send_sig() instead  of force_sig()
> have the (probably unwanted) side effect of allowing userspace to send
> the signal?

I have ran some tests, and it does look like it is now possible to send
signals to the DRBD kthread from userspace. However, ...

> I've certainly got some driver code that uses force_sig() on a kthread
> that it doesn't (ever) want userspace to signal.

... we don't feel that it is absolutely necessary for userspace to be
unable to send a signal to our kthreads. This is because the DRBD thread
independently checks its own state, and (for example) only exits as a
result of a signal if its thread state was already "EXITING" to begin
with.

As such, our priority here is to get the main issue -- DRBD hanging upon
exit -- resolved. I agree that it is not exactly desirable to have userspace
send random signals to kthreads; not for DRBD and certainly not in general.
However, we feel like it is more important to have DRBD actually work again
in 5.3.

That said, there should probably still be a way to be able to send a signal
to a kthread from the kernel, but not from userspace. I think the author of
the original patch (Eric) might have some ideas here.

Jens, could you take a look and decide whether or not it's appropriate for you
to funnel this through the linux-block tree to Linus for rc4?

> The origina1 commit says:
>> Further force_sig is for delivering synchronous signals (aka exceptions).
>> The locking in force_sig is not prepared to deal with running processes, as
>> tsk->sighand may change during exec for a running process.
> 
> I think a lot of code has assumed that the only real difference between
> send_sig() and force_sig() is that the latter ignores the signal mask.
> 
> If you need to unblock a kernel thread (eg one blocked in kernel_accept())
> in order to unload a driver, then you really don't want it to be possible
> for anything else to signal the kthread.
> 
> 	David
> 
> -
> Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
> Registration No: 1397386 (Wales)
--
Christoph Böhmwalder
LINBIT | Keeping the Digital World Running
DRBD HA —  Disaster Recovery — Software defined Storage