syscall_4294967295

[Mike Frysinger]

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 straces sees -1 in its place.
> 
> You can play with strace/tests/seccomp.c and see it yourself.

would PTRACE_O_TRACESECCOMP help here ?
-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/c3dc4eac/attachment.bin>