[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20150728120506.GF13650@port70.net>
Date: Tue, 28 Jul 2015 14:05:07 +0200
From: Szabolcs Nagy <nsz@...t70.net>
To: Andy Lutomirski <luto@...capital.net>
Cc: Rich Felker <dalias@...c.org>,
"musl@...ts.openwall.com" <musl@...ts.openwall.com>,
Alexander Larsson <alexander.larsson@...il.com>
Subject: Re: Re: Using direct socket syscalls on x86_32 where
available?
* Andy Lutomirski <luto@...capital.net> [2015-07-27 18:38:08 -0700]:
> On Mon, Jul 27, 2015 at 6:21 PM, Rich Felker <dalias@...c.org> wrote:
> > On Mon, Jul 27, 2015 at 06:04:11PM -0700, Andy Lutomirski wrote:
> >> On Mon, Jul 27, 2015 at 5:45 PM, Rich Felker <dalias@...c.org> wrote:
> >> > On Mon, Jul 27, 2015 at 04:56:51PM -0700, Andy Lutomirski wrote:
> >> >> On 07/26/2015 09:59 AM, Rich Felker wrote:
> >> >> >On Sat, Jul 25, 2015 at 10:54:28AM -0700, Andy Lutomirski wrote:
> >> >> >>On x86_32, the only way to call socket(2), etc is using socketcall.
> >> >> >>This is slated to change in Linux 4.3:
> >> >> >>
> >> >> >>https://git.kernel.org/cgit/linux/kernel/git/tip/tip.git/commit/?h=x86/asm&id=9dea5dc921b5f4045a18c63eb92e84dc274d17eb
> >> >> >>
> >> >> >>If userspace adapts by preferring the direct syscalls when available,
> >> >> >>it'll make it easier for seccomp to filter new userspace programs
> >> >> >>(and, ideally, eventually disallow socketcall for sandbox-aware code).
> >> >> >>
> >> >> >>Would musl be willing to detect these syscalls and use them if available?
> >> the totally untested code below is actually safe on pretty much any
> >> architecture that has free C11-style relaxed loads (and this code
> >> could even be switched to use actual C11 relaxed loads):
> >>
> >> volatile int socket_is_okay = true;
> >>
> >> if (socket_is_okay) {
> >> ret = socket(...);
> >> if (ret < 0) {
> >> if (ret == -ENOSYS) {
> >> socket_is_okay = false;
> >> } else {
> >> errno = -ret;
> >> return -1;
> >> }
> >>
> >> return ret;
> >> } else {
> >> usual socketcall code here;
> >> }
> >
> > This is probably workable with volatile there. Without volatile the
> > x86 memory model does not help you; the compiler can make
> > transformations that would make it unsafe even if the machine code you
> > expected the compiler to generate would be safe. But I still don't
> > like hacks like this. It's a big mess to keep it from getting used on
> > non-x86 where it would be invalid/unsafe.
>
> Why's it unsafe on non-x86? I think it's safe if all those volatile
> accesses are replaced with standard C11 relaxed accesses. The only
> thing that code requires for correctness is that a relaxed read never
> returns a result that never was nor will be written.
>
for posix conformance you would actually need volatile
sig_atomic_t which may be smaller than int, but musl
doesn't support any such arch.
i agree that relaxed memory order access is enough here.
it matters if all new socket calls are added together to
the kernel (if not, then you need one flag per syscall).
one ugliness is that there are archs with SYS_socketcall
but musl doesn't use that if SYS_socket exists.. however
on i386 the fallback is necessary.
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.
