mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@libc.org>
To: David Timber <mieabby@gmail.com>
Cc: musl@lists.openwall.com
Subject: Re: [musl] Add SYSCALL_USE_SOCKETCALL for old arch
Date: Mon, 3 Aug 2020 09:33:39 -0400	[thread overview]
Message-ID: <20200803133338.GB6949@brightrain.aerifal.cx> (raw)
In-Reply-To: <CAGYH49DtTEsUMyPRm5Y+0OT_q+HeQR9d7uiwREuKtD5-LnAUrw@mail.gmail.com>

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

  reply	other threads:[~2020-08-03 13:33 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-03  7:41 David Timber
2020-08-03 13:33 ` Rich Felker [this message]
     [not found]   ` <CAGYH49BV-SG0THP2kzbSVVRypkk0APF1MQb74geskos=dDLv6A@mail.gmail.com>
     [not found]     ` <CAGYH49Dd6qMK0pL+eGBzMZPxBqoZhRRfejnsvkkSsN+xcw4njg@mail.gmail.com>
     [not found]       ` <20200803141513.GD6949@brightrain.aerifal.cx>
     [not found]         ` <CAGYH49AEpS9_ndXP=x20Qpj7tx0RBEyt+iB5nEjD4odUW02wiQ@mail.gmail.com>
2020-08-04 18:18           ` Rich Felker
2020-08-04 18:56             ` Markus Wichmann
2020-08-04 19:15               ` Rich Felker
2020-08-06  2:18                 ` [musl] [PATCH] use new socket syscalls, fallback to socketcall Rich Felker

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200803133338.GB6949@brightrain.aerifal.cx \
    --to=dalias@libc.org \
    --cc=mieabby@gmail.com \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).