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:17:45PM +1100, Michael Ellerman wrote:
> "Dmitry V. Levin" <ldv@strace.io> writes:
[...]
> > The only case where I see some intersection is do_seccomp() where the
> > tracer would be able to see -ENOSYS in gpr[3].  However, the seccomp stop
> > is not the place where the tracer *reads* the system call exit status,
> > so whatever was written in gpr[3] before __secure_computing() is not
> > really relevant, consequently, selftests/seccomp/seccomp_bpf passes with
> > this patch applied as well as without it.
>  
> IIRC it is important for a tracer that blocks the syscall but doesn't
> explicitly set the return value. But it's only important that the
> default return value is syscall failure (ie. ENOSYS/-ENOSYS), the actual
> sign of the r3 value should be irrelevant to the tracer.
> 
> If the selftest still passes then that's probably sufficient.

Yes, I failed to explain this properly, thanks for correcting me.
With the current implementation, both -ENOSYS and ENOSYS/cr0.SO semantics
of the error code at __secure_computing() stage lead to the same result,
this is the reason why seccomp_bpf selftest passes regardless of the patch.

At any point where the tracer is entitled to interpret gpr[3] as a syscall
return value, the semantics of gpr[3] is well-defined (-ERRORCODE/cr0.SO
in non-scv case) and is a part of the ABI.

However, since we have to provide backwards compatibility with the current
inconsistent implementation, in the non-scv case we have to continue
supporting both -ENOSYS and ENOSYS/cr0.SO semantics of the syscall return
value set by the tracer at __secure_computing() stage.


-- 
ldv