Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <20200806021844.GK6949@brightrain.aerifal.cx>
Date: Wed, 5 Aug 2020 22:18:47 -0400
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: [PATCH] use new socket syscalls, fallback to socketcall

On Tue, Aug 04, 2020 at 03:15:06PM -0400, Rich Felker wrote:
> 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.

OK, that roughly works. Special care is needed for SYS_accept since it
doesn't exist on i386, m68k, or s390x and needs to be emulated with
SYS_accept4. microblaze and mips (plain o32) seem to be the only archs
that define SYS_socketcall but don't ever need to use it.

Attached is a patch that seems to work implementing the above idea
with fixups. It's not heavily tested yet.

Rich

View attachment "socketcall_fallback.diff" of type "text/plain" (3922 bytes)

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.