linux-kernel - Re: [RFC PATCH 0/8] signals: Support more than 64 signals

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: <87pmp79mxl.fsf@email.froward.int.ebiederm.org>
Date:   Tue, 04 Jan 2022 16:05:26 -0600
From:   ebiederm@...ssion.com (Eric W. Biederman)
To:     "Theodore Ts'o" <tytso@....edu>
Cc:     Walt Drummond <walt@...mmond.us>, aacraid@...rosemi.com,
        viro@...iv.linux.org.uk, anna.schumaker@...app.com, arnd@...db.de,
        bsegall@...gle.com, bp@...en8.de, chuck.lever@...cle.com,
        bristot@...hat.com, dave.hansen@...ux.intel.com,
        dwmw2@...radead.org, dietmar.eggemann@....com, dinguyen@...nel.org,
        geert@...ux-m68k.org, gregkh@...uxfoundation.org, hpa@...or.com,
        idryomov@...il.com, mingo@...hat.com, yzaikin@...gle.com,
        ink@...assic.park.msu.ru, jejb@...ux.ibm.com, jmorris@...ei.org,
        bfields@...ldses.org, jlayton@...nel.org, jirislaby@...nel.org,
        john.johansen@...onical.com, juri.lelli@...hat.com,
        keescook@...omium.org, mcgrof@...nel.org,
        martin.petersen@...cle.com, mattst88@...il.com, mgorman@...e.de,
        oleg@...hat.com, pbonzini@...hat.com, peterz@...radead.org,
        rth@...ddle.net, richard@....at, serge@...lyn.com,
        rostedt@...dmis.org, tglx@...utronix.de,
        trond.myklebust@...merspace.com, vincent.guittot@...aro.org,
        x86@...nel.org, linux-kernel@...r.kernel.org,
        ceph-devel@...r.kernel.org, kvm@...r.kernel.org,
        linux-alpha@...r.kernel.org, linux-arch@...r.kernel.org,
        linux-fsdevel@...r.kernel.org, linux-m68k@...r.kernel.org,
        linux-mtd@...ts.infradead.org, linux-nfs@...r.kernel.org,
        linux-scsi@...r.kernel.org, linux-security-module@...r.kernel.org
Subject: Re: [RFC PATCH 0/8] signals: Support more than 64 signals

"Theodore Ts'o" <tytso@....edu> writes:

> On Tue, Jan 04, 2022 at 12:00:34PM -0600, Eric W. Biederman wrote:
>> I dug through the previous conversations and there is a little debate
>> about what makes sense for SIGPWR to do by default.  Alan Cox remembered
>> SIGPWR was sent when the power was restored, so ignoring SIGPWR by
>> default made sense.  Ted Tso pointed out a different scenario where it
>> was reasonable for SIGPWR to be a terminating signal.
>> 
>> So far no one has actually found any applications that will regress if
>> SIGPWR becomes ignored by default.  Furthermore on linux SIGPWR is only
>> defined to be sent to init, and init ignores all signals by default so
>> in practice SIGPWR is ignored by the only process that receives it
>> currently.
>
> As it turns out, systemd does *not* ignore SIGPWR.  Instead, it will
> initiate the sigpwr target.  From the systemd.special man page:
>
>        sigpwr.target
>            A special target that is started when systemd receives the
>            SIGPWR process signal, which is normally sent by the kernel
>            or UPS daemons when power fails.
>
> And child processes of systemd are not ignoring SIGPWR.  Instead, they
> are getting terminated.
>
> <tytso@...c>
> 41% /bin/sleep 50 &
> [1] 180671
> <tytso@...c>
> 42% kill -PWR 180671
> [1]+  Power failure           /bin/sleep 50


That is all as expected, and does not demonstrate a regression would
happen if SIGPWR were to treat SIG_DFL as SIG_IGN, as SIGWINCH, SIGCONT,
SIGCHLD, SIGURG do.  It does show there is the possibility of problems.

The practical question is does anything send SIGPWR to anything besides
init, and expect the process to handle SIGPWR or terminate?

Possibly easier to implement (if people desire) is to simply send
SIGCONT with an si_code that indicates someone pressed the VSTATUS
key.  We have a per signal 32bit si_code space so that should
be comparatively easy.

> I claim, though, that we could implement VSTATUS without implenting
> the SIGINFO part of the feature.

I agree that is the place to start.  And if we aren't going to use
SIGINFO perhaps we could have an equally good notification method
if anyone wants one.  Say call an ioctl and get an fd that can
be read when a VSTATUS request comes in.

SIGINFO vs SIGCONT vs a fd vs something else is something we can sort
out when people get interested in modifying userspace.

Eric