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]

Date:   Mon, 5 Aug 2019 09:41:06 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Christoph Böhmwalder' 
        <christoph.boehmwalder@...bit.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

From: Christoph Böhmwalder
> Sent: 05 August 2019 10:33
> 
> 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.

In must 'clear' the signal - otherwise it won't block again.

I've also got this horrid code fragment:

    init_waitqueue_entry(&w, current);

    /* Tell scheduler we are going to sleep... */
    if (signal_pending(current) && !interruptible)
        /* We don't want waking immediately (again) */
        sleep_state = TASK_UNINTERRUPTIBLE;
    else
        sleep_state = TASK_INTERRUPTIBLE;
    set_current_state(sleep_state);

    /* Connect to condition variable ... */
    add_wait_queue(cvp, &w);
    mutex_unlock(mtxp); /* Release mutex */

where we want to sleep TASK_UNINTERRUPTIBLE but that f*cks up the 'load average',
so sleep TASK_INTERRUPTIBLE unless there is a signal pending that we want to
ignore.

	David

-
Registered Address Lakeside, Bramley Road, Mount Farm, Milton Keynes, MK1 1PT, UK
Registration No: 1397386 (Wales)