Apologies for the lateness of this stuff. I was at a conference last week when the Chrome issue was discovered and I couldn't do this properly until I got back.
Will, can you confirm that this version is okay and passes your tests? It passes mine. While there are no known seccomp users that will have trouble, SECCOMP_RET_TRAP and SECCOMP_RET_TRACE currently interact oddly with emulated vsyscalls. This might lead to ABI issues down the road (if something starts to rely on current behavior) or unexpected malfunctions (if something tries to change, say, sys_gettimeofday, into a different syscall and gets completely bogus results on a vsyscall-using distro. It's unlikely that fixing this later will cause issues, but it would be nice to nail down and document the vsyscall quirks for the first released kernel with seccomp mode 2 support. (Patch 2/2 is very much optional. It fixes a strange corner case. It ought to be fine for 3.6, since I very much doubt that any real code will hit that corner case and cause ABI problems.) Andy Lutomirski (2): seccomp: Make syscall skipping and nr changes more consistent seccomp: Future-proof against silly tracers Documentation/prctl/seccomp_filter.txt | 74 ++++++++++++++++++++-- arch/x86/include/asm/syscall.h | 11 +++ arch/x86/kernel/vsyscall_64.c | 110 +++++++++++++++++--------------- kernel/seccomp.c | 28 +++++++- 4 files changed, 163 insertions(+), 60 deletions(-) -- 1.7.7.6 -- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
