rr icon indicating copy to clipboard operation
rr copied to clipboard

Native Android Seccomp Limitations

Open StDymphna opened this issue 9 months ago • 2 comments

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.

StDymphna avatar Mar 07 '25 16:03 StDymphna

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 avatar Mar 08 '25 20:03 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.

rocallahan avatar Mar 08 '25 20:03 rocallahan