Re: [PATCH v2 1/7] powerpc: properly negate error in syscall_set_return_value()

["Dmitry V. Levin" <ldv@strace.io>]

On Sat, Jan 25, 2025 at 11:18:06PM +1100, Michael Ellerman wrote:
> Alexey Gladkov <legion@kernel.org> writes:
> >
> ...
> > I'm not a powerpc expert but shouldn't be used regs->gpr[3] via a
> > regs_return_value() in system_call_exception() ?
> 
> Yes I agree.
> 
> > notrace long system_call_exception(struct pt_regs *regs, unsigned long r0)
> > {
> > ...
> > 		r0 = do_syscall_trace_enter(regs);
> > 		if (unlikely(r0 >= NR_syscalls))
> > 			return regs->gpr[3];
> 
> This is the case where we're expecting the r3 value to be a negative
> error code, to match the in-kernel semantics. But after this change it
> would be a positive error value. It is probably harmless with the
> current code structure, but that's just luck.

I'm afraid that's not just luck.  do_seccomp() from the very beginning
supports both the generic kernel -ERRORCODE return value ABI and the
powerpc sc syscall return ABI, thanks to syscall_exit_prepare() that
converts the former to the latter.  Given that this inconsistency was
exposed to user space via PTRACE_EVENT_SECCOMP tracers for so many years,
I suppose backwards compatibility has to be provided.  Consequently, since
the point of __secure_computing() invocation and up to the point of
conversion in syscall_exit_prepare(), gpr[3] may be set according to
either of these two ABIs.  Unfortunately, this means any future attempt
to avoid the inconsistency would be inherently incomplete.

For this reason, I doubt it would make sense to include into the patch
any changes that are needed only to address this consistency issue.


-- 
ldv