Date: Thu, 30 Jul 2015 00:14:21 +0100 From: Justin Cormack <justin@...cialbusservice.com> To: Andy Lutomirski <luto@...capital.net> Cc: "musl@...ts.openwall.com" <musl@...ts.openwall.com> Subject: Re: Re: Using direct socket syscalls on x86_32 where available? On 29 July 2015 at 19:32, Andy Lutomirski <luto@...capital.net> wrote: > 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. Oh yes I forgot the socketcall args were passed as a pointer to the real args. Yeah, not worth special casing. 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.