[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID:
<SE1P216MB24840A606D9FD040F232FF2D9E372@SE1P216MB2484.KORP216.PROD.OUTLOOK.COM>
Date: Wed, 4 Dec 2024 07:00:02 +0000
From: JinCheng Li <naiveli233@...look.com>
To: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
CC: Markus Wichmann <nullplan@....net>
Subject: Re: Do we need to enhance robustness in the signal mask?
Hi
> Can you clarify what situation you're concerned about?
The specified scenario is as Markus said, I can just use pthread_sigmask(SIG_SETMASK, 0, &ss) to unblock all signals in the timer notification function. And due to the SIG_DFL handler of the SIGTIMER signal, the next timer expiration will then kill the process. I provided a demo in the email.
What really happened was that I used the interface of a third-party library in the notification function, but the interface unblocked SIGTIMER as mentioned above, and I couldn't prevent this from happening. Sadly, the third-party library is necessary and works properly in an Android environment.
In musl, I can easily get a sigset with 32, 33, 34 unblocked such as sigfillset(&set) or pthread_sigmask(0, NULL, &set) in demo. So users can also easily unblock 32, 33, 34 through this sigset, even they don't realize they're unblocking these internal signals.
Since I can set the mask of the signal through the normal sigpromask and sig*set interfaces, it's possible that the setting of the internal signal may be affected and unexpected situations may occur, especially when using the capabilities of some third-party libraries which I can't control.
So my suggestion is whether musl should be like android, protect the settings of the internal signal in some situations to enhance robustness.
> You can get a valid sigset_t lacking SIGTIMER (unconditionally) with
> pthread_sigmask(), and then set it, e.g like
> sigset_t ss;
> pthread_sigmask(SIG_SETMASK, 0, &ss);
> pthread_sigmask(SIG_SETMASK, &ss, 0);
> Honestly, this is close to the normal way to use pthread_sigmask(). The
> same holds if the first all is used to block some other signal for some
> reason and the second one then is supposed to restore the signal mask.
> And you can do that in a timer notification function, where the signal
> is supposed to be blocked. The timer thread will continue to execute
> with the signal unblocked. And since the signal disposition is set to
> SIG_DFL, and the default handling for RT signals is to terminate, the
> next timer expiration will then kill the process.
Best,
JinCheng
________________________________
From: Markus Wichmann <nullplan@....net>
Sent: Wednesday, December 4, 2024 2:18
To: musl@...ts.openwall.com <musl@...ts.openwall.com>
Subject: Re: [musl] Do we need to enhance robustness in the signal mask?
Am Tue, Dec 03, 2024 at 09:44:10AM -0500 schrieb Rich Felker:
> There are only a limited number of ways you can get a sigset_t whose
> use with sigprocmask etc. doesn't have undefined behavior. Either you
> initialize it with sigemptyset or sigfillset then modify with
> sigaddset/sigdelset, or you get it from some interface that reads back
> a sigset_t.
>
You can get a valid sigset_t lacking SIGTIMER (unconditionally) with
pthread_sigmask(), and then set it, e.g like
sigset_t ss;
pthread_sigmask(SIG_SETMASK, 0, &ss);
pthread_sigmask(SIG_SETMASK, &ss, 0);
Honestly, this is close to the normal way to use pthread_sigmask(). The
same holds if the first all is used to block some other signal for some
reason and the second one then is supposed to restore the signal mask.
And you can do that in a timer notification function, where the signal
is supposed to be blocked. The timer thread will continue to execute
with the signal unblocked. And since the signal disposition is set to
SIG_DFL, and the default handling for RT signals is to terminate, the
next timer expiration will then kill the process.
> FWIW, SIGTIMER is not of special concern. It will never be generated
> except for timer threads, and these run with it explicitly blocked.
> This is very different from the situation for SIGCANCEL or SIGSYNCCALL
> where it's critical for arbitrary threads to be able to receive them.
> Also, at some point SIGTIMER is slated to be removed in favor of using
> clock_nanosleep for SIGEV_THREAD timers rather than kernelspace
> timers unless a strong reason not to do that is discovered.
I tried looking into doing that at some point and just gave up, because
of the overrun accounting. If I understand correctly, every timer
expiration between the notification being generated and being delivered
increases the overrun counter, and for each notification it is supposed
to be latched and then reset. So for SIGEV_THREAD, that would be every
expiration between the call and the return. And for SIGEV_SIGNAL, that
would be every expiration between the signal being sent and being
handled.
All of which was too complicated for me to wrap my head around, but
maybe you have more luck.
Ciao,
Markus
Content of type "text/html" skipped
View attachment "demo.txt" of type "text/plain" (802 bytes)
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.
