[PATCH] riscv/entry: get correct syscall number from syscall_get_nr()

Aurelien Jarno aurelien at aurel32.net
Fri Nov 15 13:49:12 PST 2024


On 2024-10-28 02:45, Björn Töpel wrote:
> Thanks for helping out to dissect this! Much appreciated!
> 
> Thomas Gleixner <tglx at linutronix.de> 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 at aurel32.net                     http://aurel32.net



More information about the linux-riscv mailing list