On 27/01/2026 12:34, Jinjie Ruan wrote:

quoted

[...]

quoted

 I'm also concerned that rseq_debug_update_user_cs()
operates on instruction_pointer(regs) which is something that can be
chaned by ptrace.

Isn't that true regardless of where rseq_syscall() is called on the
syscall exit path, though?

My understanding is that if instruction_pointer(regs) is hijacked and
modified via ptrace at the syscall exit (ptrace_report_syscall_exit()),
this modification will not be observed by rseq. Specifically, in the
generic entry syscall exit path, rseq_syscall() is unable to detect such
a PC modification.

Good point. So concretely that means that currently on arm64, one could
make the rseq debug check pass/fail by using the syscall exit trap to
modify PC. OTOH this is impossible with generic entry because the rseq
check is performed first. I'm not sure this is a feature anyone has even
noticed, but it is a user-visible change indeed.

- Kevin