Native Android Seccomp Limitations

[EmmaJaneBonestell]

Because rr uses its "own syscalls", rr encounters immediate runtime failures from bad syscalls on native Android devices (e.g., within Termux).

While Android does support seccomp filtering, its security model (since Android OS 8) only allows filtering of valid syscalls. Invalid numbers will cause SIGSYS regardless of seccomp filtering.

It's still possible to setup signal/exception handlers and capture SIGSYS, so I thought about attempting this; however, I'm not familiar enough with rr's codebase, and whether that would break how rr inspects, records, etc., and did not want to waste time implementing something if so.

[rocallahan]

rr will see SIGSYS being delivered, via a ptrace stop. I think we could detect that it's a SIGSYS on an rr syscall and treat that just as if the rr syscall had executed normally and produced a syscall stop.

[rocallahan]

In other words we don't actually have to set up any SIGSYS handler. We wouldn't inject the SIGSYS signal and trigger the setting up of a signal stack frame. It should simply be a matter of treating those specific SIGSYSes as a different kind of ptrace stop. We might need to adjust some bits of tracee state to make it look like we entered the kernel.