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
pgp_u96yHEo8W.pgp
Description: PGP signature
------------------------------------------------------------------------------ Site24x7 APM Insight: Get Deep Visibility into Application Performance APM + Mobile APM + RUM: Monitor 3 App instances at just $35/Month Monitor end-to-end web transactions and take corrective actions now Troubleshoot faster and improve end-user experience. Signup Now! http://pubads.g.doubleclick.net/gampad/clk?id=272487151&iu=/4140
_______________________________________________ Strace-devel mailing list Strace-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/strace-devel