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=-2.5 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3,RCVD_IN_MSPIKE_WL, SUBJ_OBFU_PUNCT_FEW autolearn=ham autolearn_force=no version=3.4.4 Received: (qmail 15289 invoked from network); 3 Aug 2020 13:33:57 -0000 Received: from mother.openwall.net (195.42.179.200) by inbox.vuxu.org with ESMTPUTF8; 3 Aug 2020 13:33:57 -0000 Received: (qmail 7699 invoked by uid 550); 3 Aug 2020 13:33:52 -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 7681 invoked from network); 3 Aug 2020 13:33:52 -0000 Date: Mon, 3 Aug 2020 09:33:39 -0400 From: Rich Felker To: David Timber Cc: musl@lists.openwall.com Message-ID: <20200803133338.GB6949@brightrain.aerifal.cx> References: MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Subject: Re: [musl] Add SYSCALL_USE_SOCKETCALL for old arch On Mon, Aug 03, 2020 at 05:11:59PM +0930, David Timber wrote: > The following arches do not have __NR_SOCKET in kernel version 2.4.x, > but musl makes call to socket(), resulting in ENOSYS: > > * arm > * powerpc > * powerpc64 > * sh (32bit only) The minimum supported kernel version is 2.6.0; anything earlier is on an as-it-happens-to-work basis. In particular threads and a good deal of related functionality will not work at all on 2.4, and on arm nothing at all works on 2.4 because the initial __ARM_NR_set_tls syscall fails with ENOSYS. The others however should work minimally since the thread pointer is kept in a userspace-accessible register. Which arch(s) are you trying where you get far enough to try to open a socket? > Adding `#define SYSCALL_USE_SOCKETCALL` would solve the problem, but > doing so will incur a bit of overhead. uClibc checks if `__NR_socket` > is defined. I suggest you do the same. > > https://git.uclibc.org/uClibc/tree/libc/inet/socketcalls.c#n387 This does not work since __NR_socket is always defined. I suppose uClibc does some thing where you're expected to compile with kernel headers from the kernel you intend to run with and things subtly break if they mismatch; musl does not do this and does not use kernel headers at all. This is a runtime issue that can't be decided at compiletime. Since 2.4 is not actually supported, I don't want to do anything that increases complexity here for its sake. However, there have been requests to use recently-added SYS_socket, etc. for archs that previously used SYS_socketcall because the new ones are friendlier to seccomp filtering. The right resolution to the problem you're seeing is probably switching to always using the new syscalls first if they're available, only falling back to SYS_socketcall if they fail with ENOSYS (and only on archs where SYS_socketcall exists to begin with), and getting rid of the SYSCALL_USE_SOCKETCALL macro entirely since we'll be treating all archs the same. Does this sound reasonable? Rich