[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CALCETrXaAAKfM9HHeBXUeRS=ftnL0HGfUkxubvmeVeGSg-_0Qg@mail.gmail.com>
Date: Wed, 29 Jul 2015 11:32:09 -0700
From: Andy Lutomirski <luto@...capital.net>
To: Justin Cormack <justin@...cialbusservice.com>
Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com>
Subject: Re: Re: Using direct socket syscalls on x86_32 where available?
On Wed, Jul 29, 2015 at 5:51 AM, Justin Cormack
<justin@...cialbusservice.com> wrote:
> 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.
With socketcall, you can filter on the call number, but you can't
filter on the arguments since they're in memory. So you can block
socket(2) entirely, but you can't block all but AF_INET, for example.
--Andy
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.
