Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Tue, 4 Aug 2020 15:15:06 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: Add SYSCALL_USE_SOCKETCALL for old arch

On Tue, Aug 04, 2020 at 08:56:42PM +0200, Markus Wichmann wrote:
> On Tue, Aug 04, 2020 at 02:18:45PM -0400, Rich Felker wrote:
> > Of these, only ppc, ppc64, sh, and possibly s390 (we only support
> > 64-bit "s390x" and I'm not sure if it ever lacked the broken-down
> > syscalls) are relevant. The rest are either unsupported by musl
> > (including pre-EABI arm) or already using SYS_socketcall.
> 
> According to musl source, all currently supported architectures have
> __NR_socket (I didn't check the other calls; I just assumed that
> __NR_socket was a stand-in for all the other ones).
> 
> Therefore the required change can be performed by changing the
> __socketcall macro (and __socketcall_cp of course). Something like this,
> maybe? (If using GCC statement expressions is alright):
> 
> #ifdef __NR_socketcall
> #define __socketcall(nm, a, b, c, d, e, f) \
>     ({int r = __syscall(__NR_ ## nm, a, b, c, d, e, f); \
>     if (r == -ENOSYS) \
>         r = __syscall(__NR_socketcall, __SC_ ## nm, \
>             (long[6]){(long)a, (long) b, (long)c, (long)d, (long)e, (long) f});
>     r;})
> #else
> #define __socketcall(nm, a, b, c, d, e, f) __syscall(__NR_ ## nm, a, b, c, d, e, f)
> #endif

This would work, but we don't use statement-expressions in musl. I
think an alternative with an inline function would be trivial, though:

static inline long __socketcall(int sys, int sock, long a, long b, long c, long d, long e, long f)
{
	long r = __syscall(sys, a, b, c, d, e, f);
	if (r != -ENOSYS) return r;
	return __syscall(SYS_socketcall, sock, ((long[6]){a, b, c, d, e, f}));
}
#define __socketcall(nm, a, b, c, d, e, f) __socketcall(SYS_##nm, __SC_##nm, \
	(long)(a), (long)(b), (long)(c), (long)(d), (long)(e), (long)(f))

However it may (will?) end up including SYS_socketcall fallback code
even on archs that never need it if SYS_socketcall is defined.
Probably arch/*/syscall_arch.h should #undef SYS_socketcall if it's
never needed. I'm not sure if there are any such archs.

I kinda just thought of getting rid of the __socketcall abstraction,
but indeed it looks like a lot of ugly boilerplate to duplicate across
~15 functions, so I think keeping it in src/internal/syscall.h makes
the most sense.

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.