[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200803133338.GB6949@brightrain.aerifal.cx>
Date: Mon, 3 Aug 2020 09:33:39 -0400
From: Rich Felker <dalias@...c.org>
To: David Timber <mieabby@...il.com>
Cc: musl@...ts.openwall.com
Subject: Re: 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
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.
