syscall_4294967295

[Mike Frysinger]

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 Mon, Feb 15, 2016 at 12:12:09PM +0100, Pas wrote:
> > > > Thanks for the quick response and for the hint! After testing with
> > > > -fveseccomp,prctl
> > > > it turns out that:
> > > > 
> > > > docker-engine 1.10.1-0~wily uses seccomp (prctl PR_SET_SECCOMP,
> > > > SECCOMP_MODE_FILTER and PR_CAPBSET_DROP ...), whereas 1.10.1-0~jessie
> > > > doesn't. Though eventually by default Docker will filter out (almost all?)
> > > > syscalls:
> > > > https://docs.docker.com/engine/reference/run/#runtime-privilege-and-linux-capabilities
> > > 
> > > 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.
-mike
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 819 bytes
Desc: Digital signature
URL: <http://lists.strace.io/pipermail/strace-devel/attachments/20160215/75a2bf69/attachment.bin>