`recvmmsg` is disallowed by seccomp on Android x86

[mxinden]

What happened

We attempted switching Firefox Nightly to use quinn-udp for QUIC UDP I/O by default recently, though we had to roll back due to an error on Android x86. Investigating further, it seems like seccomp on Android x86 disallows sendmsg and recvmmsg. All details are in Bugzilla Bug 1910594 and 1910360.

Reasoning

Looking at e.g. Android 13's SYSCALLS.TXT we can see support for sendmsg and recvmmsg on 64bit (lp64) and ARM:

# sockets
// [...]
ssize_t       __sendmsg:sendmsg(int, const struct msghdr*, unsigned int)  arm,lp64
// [...]
int           __recvmmsg:recvmmsg(int, struct mmsghdr*, unsigned int, int, const struct timespec*)   arm,lp64

While on x86, only the indirect calls through socketcall are allowed:

# sockets for x86. These are done as an "indexed" call to socketcall syscall.
// [...]
int           __sendmsg:socketcall:16(int, const struct msghdr*, unsigned int)  x86
// [...]
int           __recvmmsg:socketcall:19(int, struct mmsghdr*, unsigned int, int, const struct timespec*)   x86

Potential Solution

libuv has faced the same issue (see libuv/libuv#2923). On x86 they use the indirect syscalls through socketcall (see libuv/libuv#2925).

Historical context

The above might be due to historical reasons:

On x86-32, socketcall() was historically the only entry point for
the sockets API. However, starting in Linux 4.3, direct system
calls are provided on x86-32 for the sockets API.

https://man7.org/linux/man-pages/man2/socketcall.2.html

---

I still have to investigate a bit before proposing a fix. Opening this issue early to track progress.

[Ralith]

That's a weird one. Can we push for a fix upstream? Bearing mind that we'll need to work around the issue on older devices anyway.

[djc]

That's a weird one. Can we push for a fix upstream? Bearing mind that we'll need to work around the issue on older devices anyway.

By upstream, do you mean Android? If so, Android 13 is from 2022 so I'm assuming they'll be reluctant to put in fixes like this.

[Ralith]

By upstream, do you mean Android?

Right.

Android 13 is from 2022 so I'm assuming they'll be reluctant to put in fixes like this.

I couldn't guess either way, but it's not clear from the description if this has already been fixed in newer Android versions. Would be nice to make things less bad in the future, if not.

[mxinden]

Can we push for a fix upstream?

Intuitively I don't expect that such a pervasive change to a systems default seccomp filters on an ancient platform like Android x86 would be accepted. That said, I don't have any experience interacting with these projects.

For comparison, next to libuv mentioned above, here is what mio and Rust's libc did. The same problem applies not only to sendmsg and to recvmmsg but also to the accept system call family. While accept is supported on Android x86, accept4 is disallowed by seccomp.

• Fix in Rust's libc using accept4 through socketcall instead.
  • Accepting Incoming TCP Connections fails on Android rust-lang/rust#82400
  • Implement accept4 on x86 android with socketcall syscall. rust-lang/libc#2079 (merged through bot, not GitHub)
• Fix in mio using accept instead.
  • Android SECCOMP forbids accept4 on x86 tokio-rs/mio#1445
  • Use accept() instead of accept4() on x86 Android tokio-rs/mio#1446

Android 13 is from 2022 so I'm assuming they'll be reluctant to put in fixes like this.

I couldn't guess either way, but it's not clear from the description if this has already been fixed in newer Android versions. Would be nice to make things less bad in the future, if not.

As far as I can tell, it is not fixed in the most recent Android version, that is Android 14. See recvmmsg call once defined for arm and lp64 and once for x86 in SYSCALLS.TXT.

[mxinden]

With #1966 merged and released, this is fixed. 😮‍💨

As always, thank you for your help Dirkjan and Benjamin!