On 2024-10-28 02:45, Björn Töpel wrote:
Thanks for helping out to dissect this! Much appreciated!
Thomas Gleixner tglx@linutronix.de writes:
Let me look at your failure analysis from your first reply:
strace "tracing": Requires that regs->a0 is not tampered with prior ptrace notification
E.g.: | # ./strace / | execve("/", ["/"], 0x7ffffaac3890 /* 21 vars */) = -1 EACCES (Permission denied) | ./strace: exec: Permission denied | +++ exited with 1 +++ | # ./disable_ptrace_get_syscall_info ./strace / | execve(0xffffffffffffffda, ["/"], 0x7fffd893ce10 /* 21 vars */) = -1 EACCES (Permission denied) | ./strace: exec: Permission denied | +++ exited with 1 +++
In the second case, arg0 is prematurely set to -ENOSYS (0xffffffffffffffda).
That's expected if ptrace_get_syscall_info() is not used. Plain dumping registers will give you the current value on all architectures. ptrace_get_syscall_info() exist exactly for that reason.
Noted! So this shouldn't be considered as a regression. IOW, the existing upstream code is OK for this scenario.
Not however that it breaks some programs, for instance I arrived on this thread by debugging python-ptrace. I'll try to look at adding support for ptrace_get_syscall_info(), but I am afraid we will find more broken programs.
Regards Aurelien
[1] https://buildd.debian.org/status/fetch.php?pkg=python-ptrace&arch=riscv6...