0 libc.so + 0xcf00 1 libxul.so!getifaddrs [ifaddrs_android.cpp : 119 + 0x7] 2 libxul.so!sctp_init_vrf_list [sctp_bsd_addr.c : 460 + 0x9] 3 libxul.so!sctp_pcb_init [sctp_pcb.c : 6745 + 0x5] 4 libxul.so!sctp_init [sctp_usrreq.c : 162 + 0x3] 5 libxul.so!usrsctp_init [user_socket.c : 81 + 0x3] 6 libxul.so!mozilla::DataChannelConnection::Init(unsigned short, unsigned short, bool) [DataChannel.cpp : 343 + 0xb] 7 libxul.so!sipcc::PeerConnectionImpl::EnsureDataConnection(unsigned short) [PeerConnectionImpl.cpp : 952 + 0xf] 8 libxul.so!sipcc::PeerConnectionImpl::CreateDataChannel(nsAString_internal const&, nsAString_internal const&, unsigned short, bool, unsigned short, unsigned short, bool, unsigned short, nsDOMDataChannel**) [PeerConnectionImpl.cpp : 1030 + 0x3] 9 libxul.so!sipcc::PeerConnectionImpl::CreateDataChannel(nsAString_internal const&, nsAString_internal const&, unsigned short, bool, unsigned short, unsigned short, bool, unsigned short, mozilla::ErrorResult&) [PeerConnectionImpl.cpp : 1004 + 0x13] 10 libxul.so!mozilla::dom::PeerConnectionImplBinding::createDataChannel [PeerConnectionImplBinding.cpp : 917 + 0x2d] This should be remoted to the parent process at some point in this stack.

Bug 916427 and changes to the config we use should eliminate any external socket creation.

Should this be marked as depending on bug 916427?

A relevant fact: our content processes already can't create AF_INET or AF_INET6 sockets — they aren't in the AID_NET group and the kernel has CONFIG_ANDROID_PARANOID_NETWORK=y. So if usrsctp is trying to do any of that in the content process, then it's already broken on b2g.

If I modify the syscall filter to reject all socket()s with EACCES, then the mochitests in gecko/dom/media/tests all pass and the test at http://mozilla.github.io/webrtc-landing/data_test.html appears to work. So that seems to also be possible as a workaround (and indicates that whatever is going on in sctp_pcb_init isn't actually necessary).

This is no longer a seccomp blocker, as of bug 974230; clearing needinfo.

Since we landed Bug 916427 I should look at this again - the dependency was missing

Michael - FYI. I'll look at this soon

The call is needed if you want to support SCTP/IPv4 or SCTP/IPv6 or SCTP/UDP/IPv4 or SCTP/UDP/IPv6. However, for SCTP/DTLS/UDP/IPv4 or SCTP/DTLS/UDP/IPv6 as used by WebRTC this is not needed. You can disable the support of SCTP/IPv4 or SCTP/IPv6 or SCTP/UDP/IPv4 or SCTP/UDP/IPv6 by NOT defining INET and INET6 when compiling the usrsctp stack and in all files which include usrsctp.h. You can remove INET from https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/src/moz.build#56 https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/datachannel/moz.build#26 and INET6 from https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/src/moz.build#64 https://dxr.mozilla.org/mozilla-central/source/netwerk/sctp/datachannel/moz.build#30 There should be no change for WebRTC.

Comment on attachment 8817593 [details] Bug 969715: remove INET and INET6 from sctp build env. https://reviewboard.mozilla.org/r/97824/#review98194

Pushed by drno@ohlmeier.org: https://hg.mozilla.org/integration/autoland/rev/572fdb501218 remove INET and INET6 from sctp build env. r=jesup