In #75133 (comment) @dyhkwong says:
This seems causing a "seccomp prevented call to disallowed arm system call 422" crash on Android <= 10. futex_time64 is blocked by seccomp on Android <= 10.
Reference: https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3987
For context in #75133 we had issues where the runtime would fail to start when building linux with CONFIG_COMPAT_32BIT_TIME=n on 32bits systems.
This setting cause old 32bits time syscalls to become unavailable aiding to find 2038Y bugs.
In commits 4620db7 and 3cf1aaf we added code to test if newer linux 64 bits syscalls.
To do so we call the 64bits time syscalls first, and if we got ENOSYS (which a kernel before their introduction would return) we fall back to the old 32bits syscalls.
However according to the quote above, when Android versions bellow 10 get the 64bits syscall rather than returning an error back to us, they terminate the program with a seccomp violation.
Note: I am not able to easily to test this and I have not ran the code.
In #75133 (comment) @dyhkwong says:
For context in #75133 we had issues where the runtime would fail to start when building linux with
CONFIG_COMPAT_32BIT_TIME=non 32bits systems.This setting cause old 32bits time syscalls to become unavailable aiding to find 2038Y bugs.
In commits 4620db7 and 3cf1aaf we added code to test if newer linux 64 bits syscalls.
To do so we call the 64bits time syscalls first, and if we got ENOSYS (which a kernel before their introduction would return) we fall back to the old 32bits syscalls.
However according to the quote above, when Android versions bellow 10 get the 64bits syscall rather than returning an error back to us, they terminate the program with a seccomp violation.
Note: I am not able to easily to test this and I have not ran the code.