linux-kernel - RE: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user

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: <6e9b964b08d84c99980b1707e5fe3d1d@AcuMS.aculab.com>
Date:   Thu, 13 Jun 2019 08:48:41 +0000
From:   David Laight <David.Laight@...LAB.COM>
To:     'Oleg Nesterov' <oleg@...hat.com>
CC:     "'Eric W. Biederman'" <ebiederm@...ssion.com>,
        'Andrew Morton' <akpm@...ux-foundation.org>,
        'Deepa Dinamani' <deepa.kernel@...il.com>,
        "'linux-kernel@...r.kernel.org'" <linux-kernel@...r.kernel.org>,
        "'arnd@...db.de'" <arnd@...db.de>,
        "'dbueso@...e.de'" <dbueso@...e.de>,
        "'axboe@...nel.dk'" <axboe@...nel.dk>,
        "'dave@...olabs.net'" <dave@...olabs.net>,
        "'e@...24.org'" <e@...24.org>,
        "'jbaron@...mai.com'" <jbaron@...mai.com>,
        "'linux-fsdevel@...r.kernel.org'" <linux-fsdevel@...r.kernel.org>,
        "'linux-aio@...ck.org'" <linux-aio@...ck.org>,
        "'omar.kilani@...il.com'" <omar.kilani@...il.com>,
        "'tglx@...utronix.de'" <tglx@...utronix.de>,
        'Al Viro' <viro@...IV.linux.org.uk>,
        'Linus Torvalds' <torvalds@...ux-foundation.org>,
        "'linux-arch@...r.kernel.org'" <linux-arch@...r.kernel.org>
Subject: RE: [RFC PATCH 1/5] signal: Teach sigsuspend to use set_user_sigmask

From: David Laight
> Sent: 12 June 2019 15:18
> From: Oleg Nesterov
> > Sent: 12 June 2019 14:46
> > On 06/11, David Laight wrote:
> > >
> > > If I have an application that has a loop with a pselect call that
> > > enables SIGINT (without a handler) and, for whatever reason,
> > > one of the fd is always 'ready' then I'd expect a SIGINT
> > > (from ^C) to terminate the program.
> >
> > This was never true.
> >
> > Before Eric's patches SIGINT can kill a process or not, depending on timing.
> > In particular, if SIGINT was already pending before pselect() and it finds
> > an already ready fd, the program won't terminate.
> 
> Which matches what I see on a very old Linux system.
> 
> > After the Eric's patches SIGINT will only kill the program if pselect() does
> > not find a ready fd.
> >
> > And this is much more consistent. Now we can simply say that the signal will
> > be delivered only if pselect() fails and returns -EINTR. If it doesn't have
> > a handler the process will be killed, otherwise the handler will be called.
> 
> But is it what the standards mandate?
> Can anyone check how Solaris and any of the BSDs behave?
> I don't have access to any solaris systems (I doubt I'll get the disk to
> spin on the one in my garage).
> I can check NetBSD when I get home.

I tested NetBSD last night.
pselect() always calls the signal handlers even when an fd is ready.
I'm beginning to suspect that this is the 'standards conforming' behaviour.
I don't remember when pselect() was added to the ToG specs, it didn't
go through XNET while I  was going to the meetings.

	David

> 
> The ToG page for pselect() http://pubs.opengroup.org/onlinepubs/9699919799/functions/pselect.html
> says:
>     "If sigmask is not a null pointer, then the pselect() function shall replace
>     the signal mask of the caller by the set of signals pointed to by sigmask
>     before examining the descriptors, and shall restore the signal mask of the
>     calling thread before returning."
> Note that it says 'before examining the descriptors' not 'before blocking'.
> Under the general description about signals it also says that the signal handler
> will be called (or other action happen) when a pending signal is unblocked.
> So unblocking SIGINT (set to SIG_DFL) prior to examining the descriptors
> should be enough to cause the process to exit.
> The fact that signal handlers are not called until 'return to user'
> is really an implementation choice - but (IMHO) it should appear as if they
> were called at the time they became unmasked.
> 
> If nothing else the man pages need a note about the standards and portability.
> 
> 	David

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