syscall_4294967295

[Dmitry V. Levin]

On Mon, Feb 15, 2016 at 10:11:41AM -0500, Mike Frysinger wrote:
> On 15 Feb 2016 17:50, Dmitry V. Levin wrote:
> > On Mon, Feb 15, 2016 at 09:30:18AM -0500, Mike Frysinger wrote:
> > > On 15 Feb 2016 15:21, Dmitry V. Levin wrote:
[...]
> > > > On entering syscall, seccomp kernel hooks are executed before ptrace
> > > > kernel hooks.  As result, when some syscall is blocked by seccomp filter
> > > > using SECCOMP_RET_ERRNO statement, on many architectures including x86 and
> > > > x86_64 the syscall number is clobbered and strace sees -1 in its place.
> > > > 
> > > > You can play with strace/tests/seccomp.c and see it yourself.
> > > 
> > > would PTRACE_O_TRACESECCOMP help here ?
> > 
> > Only for SECCOMP_RET_TRACE actions.
> 
> oh i misread ... i was thinking it was for all ret operations.
> can we get the seccomp core to save its original state in a way
> we can get at later, perhaps via a new PTRACE_GETSECCOMPDATA ?
> that'd tell us which SECCOMP_RET_xxx was used and the value that
> was in there before.  we would need a new PTRACE_EVENT_xxx so we
> don't have to run it all the time.

Yes, I think something of this kind could be implemented for
SECCOMP_PHASE1_SKIP actions (i.e. SECCOMP_RET_ERRNO and SECCOMP_RET_TRAP).


-- 
ldv
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160215/17fdaae0/attachment.bin>