[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20241203144409.GL10433@brightrain.aerifal.cx>
Date: Tue, 3 Dec 2024 09:44:10 -0500
From: Rich Felker <dalias@...c.org>
To: JinCheng Li <naiveli233@...look.com>
Cc: musl <musl@...ts.openwall.com>
Subject: Re: Do we need to enhance robustness in the signal mask?
On Tue, Dec 03, 2024 at 03:06:39AM +0000, JinCheng Li wrote:
> Hi
>
>
> The signal 32(SIGTIMER) will only used in musl timer and block for
> the SIGEV_THREAD. I think it can be seen as a special internal
> signal like 34(SIGSYNCCALL).
>
> But in sigprocmask and pthread_sigmask, musl lacks protection for
> these internal signals. Users can modify the shielding status of
> such signals which may cause problems with signal response. For
> example, I can cancel the masking of signal 32 for the SIGEV_THREAD,
> as aresult, the timing thread can exits abnormally.
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.
In musl, we disallow creation of invalid signal sets via the sig*set
function, rather than attempting to alter the set when it's installed
via sigprocmask. One reason it's done this way is that returning from
a signal handler also installs a sigset_t, and we don't have control
over that code path (and can't unless we opt to wrap signal handling).
> But in android, there is a function "filter_reserved_signals" used
> in sigprocmask to protect the internal signals state from being
> modified.
>
> Considering that upper-layer users may not know the internl signals
> such as 32 has been blocked, should we add a default block for these
> signals in pthread_sigmask like android to enhance the signal
> robustness? Or is there other considerations?
Can you clarify what situation you're concerned about?
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.
Rich
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.
