Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Thu, 30 Jul 2015 00:14:21 +0100
From: Justin Cormack <>
To: Andy Lutomirski <>
Cc: "" <>
Subject: Re: Re: Using direct socket syscalls on x86_32 where available?

On 29 July 2015 at 19:32, Andy Lutomirski <> wrote:
> On Wed, Jul 29, 2015 at 5:51 AM, Justin Cormack
> <> wrote:
>> On 28 July 2015 at 08:44, Alexander Larsson <> wrote:
>>> On Tue, Jul 28, 2015 at 1:56 AM, Andy Lutomirski <> 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.

Oh yes I forgot the socketcall args were passed as a pointer to the
real args. Yeah, not worth special casing.


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.