[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAK4o1WxxCZrsrPrJzHw8MfqhmSc-YPOWPMy8zR7r2ntirec1=w@mail.gmail.com>
Date: Wed, 29 Jul 2015 13:51:55 +0100
From: Justin Cormack <justin@...cialbusservice.com>
To: musl@...ts.openwall.com
Cc: Andy Lutomirski <luto@...capital.net>
Subject: Re: Re: Using direct socket syscalls on x86_32 where available?
On 28 July 2015 at 08:44, Alexander Larsson <alexander.larsson@...il.com> wrote:
> On Tue, Jul 28, 2015 at 1:56 AM, Andy Lutomirski <luto@...capital.net> wrote:
>>
>> One way to implement it would be to favor the new syscalls but to set some
>> variable the first time one of them returns ENOSYS. Once that happens,
>> either all of them could fall back to socketcall or just that one syscall
>> could.
>>
>> Or you could just avoid implementing it and see if anyone complains. It's
>> plausible that xdg-app might start requiring the new syscalls (although it
>> would presumably not kill you if tried to use socketcall).
>>
>> Alex, if glibc started using the new syscalls, would you want to require
>> them inside xdg-app?
>
> Probably not. At this point 32bit x86 just is not interesting enough
> for such extra pain. We'll just not filter on address types on 32bit.
Why cant you write seccomp rules for socketcall too? It is just an
extra register to match on (and libseccomp could perhaps be taught to
make it easier). If the answer is because nobody cares about 32 bit
x86 then I understand.
Justin
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.
