On 2024-10-28 02:45, Björn Töpel wrote:
> Thanks for helping out to dissect this! Much appreciated!
>
> Thomas Gleixner <tglx@xxxxxxxxxxxxx> writes:
>
> > Let me look at your failure analysis from your first reply:
> >
> >> 1. 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=riscv64&ver=0.9.9-0.1%2Bb2&stamp=1731547088&raw=0
--
Aurelien Jarno GPG: 4096R/1DDD8C9B
aurelien@xxxxxxxxxxx http://aurel32.net
