From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.3 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 10852 invoked from network); 30 Sep 2020 00:10:18 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 30 Sep 2020 00:10:18 -0000 Received: (qmail 31965 invoked by uid 550); 30 Sep 2020 00:10:15 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 31944 invoked from network); 30 Sep 2020 00:10:14 -0000 Date: Tue, 29 Sep 2020 20:10:02 -0400 From: Rich Felker To: Jesse Hathaway Cc: musl@lists.openwall.com Message-ID: <20200930001001.GI17637@brightrain.aerifal.cx> References: <20200929183644.GE17637@brightrain.aerifal.cx> <20200929203407.GH17637@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20200929203407.GH17637@brightrain.aerifal.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Re: Pending patches for MT-fork stuff On Tue, Sep 29, 2020 at 04:34:07PM -0400, Rich Felker wrote: > On Tue, Sep 29, 2020 at 01:51:30PM -0500, Jesse Hathaway wrote: > > On Tue, Sep 29, 2020 at 1:36 PM Rich Felker wrote: > > > Can you provide an strace (with -f) showing the hang? It's probably > > > not related to this since fork does not seem to be involved. Depending > > > on how you're using Go, it may just be Go bypassing libc then trying > > > to use libc functions, which at least used to be a big problem; I > > > don't know if it's fixed nowadays or not. > > > > Thanks Rich, for taking a look, I have attached an strace of the > > program compiled against musl & glibc. The first call to setreuid > > succeeds in both, but the second call fails under musl. Jesse > > The problem is this line: > > > 8238 rt_sigprocmask(SIG_SETMASK, ~[HUP INT QUIT ILL TRAP ABRT BUS FPE SEGV TERM STKFLT CHLD PROF SYS RTMIN RT_1], > > Something broken in the Go runtime is bypassing libc and either > calling SYS_rt_sigprocmask itself, or calling the libc sigprocmask > function with a sigset_t it produced itself, blocking a libc-internal > signal. This makes it invalid to make any further use of libc. > > Either it (the Go runtime) needs to manipulate sigset_t objects via > the public APIs for them (sigfillset, sigaddset, etc.) or its wrapper > for sigprocmask needs to convert the Go-manipulated sigset_t to one > valid for libc by iterating over the bits and using sigaddset, so that > invalid bits don't end up in the one passed to libc. Here is the offending code: https://github.com/golang/go/blob/a413908dd064de6e3ea5b8d95d707a532bd3f4c8/src/runtime/signal_unix.go#L866 It should be calling sigfillset() (from libc) to get the starting sigset_t rather than using its own all-one-bits initializer. There may be other places in the runtime where the same error is made. It looks like blockableSig (line 1132) is intended to do something here, but has hard-coded (somewhere else) glibc knowledge rather than probing via (libc's) sigaddset whether the signal number is valid. This might be a preferred point to fix it at. Rich