On Sat, Jan 25, 2025 at 11:18:06PM +1100, Michael Ellerman wrote:
> Alexey Gladkov <leg...@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
