[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <1342279974-26917-3-git-send-email-wad@chromium.org>
Date: Sat, 14 Jul 2012 10:32:54 -0500
From: Will Drewry <wad@...omium.org>
To: linux-kernel@...r.kernel.org, torvalds@...ux-foundation.org
Cc: fengxj325@...il.com, eparis@...hat.com, keescook@...omium.org,
james.l.morris@...cle.com, hpa@...or.com, cevans@...omium.org,
luto@....edu, rob@...dley.net, linux-doc@...r.kernel.org,
Will Drewry <wad@...omium.org>
Subject: [PATCH 3/3] Documentation: add a caveat for seccomp filter and vsyscall emulation
With the addition of seccomp support to vsyscall emulation:
http://permalink.gmane.org/gmane.linux.kernel/1327732
and the prior patch in this series.
Update the documentation to indicate quirky behaviors when the 'ip' is
in the vsyscall page and vsyscall emulation is in effect.
Signed-off-by: Will Drewry <wad@...omium.org>
---
Documentation/prctl/seccomp_filter.txt | 22 ++++++++++++++++++++++
1 file changed, 22 insertions(+)
diff --git a/Documentation/prctl/seccomp_filter.txt b/Documentation/prctl/seccomp_filter.txt
index 597c3c5..67ed88b 100644
--- a/Documentation/prctl/seccomp_filter.txt
+++ b/Documentation/prctl/seccomp_filter.txt
@@ -161,3 +161,25 @@ architecture supports both ptrace_event and seccomp, it will be able to
support seccomp filter with minor fixup: SIGSYS support and seccomp return
value checking. Then it must just add CONFIG_HAVE_ARCH_SECCOMP_FILTER
to its arch-specific Kconfig.
+
+
+Caveats
+-------
+
+On x86-64 with vsyscall emulation enabled and while servicing a
+vsyscall-emulated system call:
+- A return value of SECCOMP_RET_TRAP will set a si_call_addr pointing to
+ the vsyscall entry for the given call and not the address after the
+ 'syscall' instruction. Any code which wants to restart the call
+ should return to that address and code wishing to return simulating
+ completion may either sigreturn normally or simulate a ret instruction
+ and use the return address from the stack.
+- A return value of SECCOMP_RET_TRACE will signal the tracer as usual,
+ but the syscall may not be changed to another system call using the
+ orig_rax register. It may only be changed to a different value in
+ order to skip the currently emulated call and any change will result
+ in that behavior. The remainder of the registers may be altered as
+ usual.
+- Detection of this quirky behavior may be done by checking for getcpu,
+ time, or gettimeofday and if the si_call_addr or rip is in the
+ vsyscall page, specifically at the start of the specific entry call.
--
1.7.9.5
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists