On Sat, Jan 25, 2025 at 11:17:45PM +1100, Michael Ellerman wrote: > "Dmitry V. Levin" <l...@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
