[PATCH 3.5 0/2] seccomp and vsyscall fixes

[Andy Lutomirski <luto@amacapital.net>]

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