[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID:
<SE1P216MB2484ECA6007550FAE404DF749E3E2@SE1P216MB2484.KORP216.PROD.OUTLOOK.COM>
Date: Wed, 11 Dec 2024 16:51:43 +0000
From: JinCheng Li <naiveli233@...look.com>
To: musl <musl@...ts.openwall.com>
Subject: Re: Do we need to enhance robustness in the signal mask?
HI
> Either we need to make it so there's no way
> to get a (valid, non-UB) sigset_t with SIGTIMER unblocked, or we just
> need to make it so it doesn't matter if it's unblocked or so unblocked
> is the desired state.
1.Use a noop handler instead of SIG_DFL for SIGTIMER. In this way, no matter how the user operates the sigmask, there is no need to worry the process exited unexpectedly.
2.To avoid frequent signal responses, re-block SIGTIMER after each notify is executed in SIGEV-THREAD.
This method can skip the additional protection of internal signals and prevent developers from being aware of changes in sig*set.
Does this introduce other risks, for example, if sigwaitinfo is triggered after the handler responds, is it possible to cause time response abnormality?
POSIX does not appear to restrict the behavior of this signal. Is the old SIG_DFL for SIGTIMER necessary?
Best,
JinCheng
________________________________
From: Rich Felker <dalias@...c.org>
Sent: Saturday, December 7, 2024 13:01
To: JinCheng Li <naiveli233@...look.com>
Cc: musl@...ts.openwall.com <musl@...ts.openwall.com>; Markus Wichmann <nullplan@....net>
Subject: Re: [musl] Do we need to enhance robustness in the signal mask?
On Fri, Dec 06, 2024 at 01:24:20PM +0000, JinCheng Li wrote:
> Hi
>
> > The easiest fix for the instant bug would probably be to just not mask
> > SIGTIMER out of the old signal mask returned by pthread_sigmask(). We
> > don't really care if it is blocked or not in most threads and explicitly
> > block it in the timer thread. This way, the signal just keeps its
> > blocking status forever in all other threads, and remains blocked in the
> > timer thread.
>
> Maybe just judge the old sigset in pthread_sigmask, if SIGTIMER in
> old sigset is blocked, it should be in a timer thread, we can just
> block SIGTIMER whatever is set for SIGTIMER in new sigset. If
> SIGTIMER in old sigset is unblocked, just remain its status set by
> new sigset. As long as it is not in a timer thread, the status of
> SIGTIMER is unblocked or blocked doesn't affect anything.
As I've said repeatedly, this can't be solved in
pthread_sigmask/sigprocmask. There are ways to install sigsets that
don't go thru this path. Either we need to make it so there's no way
to get a (valid, non-UB) sigset_t with SIGTIMER unblocked, or we just
need to make it so it doesn't matter if it's unblocked or so unblocked
is the desired state. The latter approach looks like it fixes other
things too.
Rich
Content of type "text/html" skipped
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
