| Message ID | 1329422549-16407-5-git-send-email-wad@chromium.org |
|---|---|
| State | Not Applicable, archived |
| Delegated to: | David Miller |
| Headers | show |
On Thu, Feb 16, 2012 at 12:02, Will Drewry <wad@chromium.org> wrote: > Adds a new return value to seccomp filters that triggers a SIGTRAP to be delivered with the new TRAP_SECCOMP si_code. > > This allows in-process system call emulation -- including just specifying an errno or cleanly dumping core -- rather than just dying. SIGTRAP might not be the ideal choice of signal number, as it can make it very difficult to debug the program in gdb. Other than that, I love this feature. It'll significantly simplify the code that we have in Chrome. Markus -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On Thu, Feb 16, 2012 at 2:24 PM, Markus Gutschke <markus@chromium.org> wrote: > SIGTRAP might not be the ideal choice of signal number, as it can make it > very difficult to debug the program in gdb. True enough. In theory, we could use the lower 16-bits of the return value to let the bpf program set a signal, but not all signals are masked synchronous and those that are probably get gdb's attention, just not a severely :) (ILL, SEGV, BUS, TRAP, FPE). Perhaps SIGILL is a logically appropriate option -- or letting the api user decide from the SYNCHRONOUS_MASK set. I'm open to whatever makes sense, though. (I wasn't even sure if it was kosher to add a new TRAP_SECCOMP value.) cheers! will -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
On 02/16/2012 12:28 PM, Markus Gutschke wrote: > On Thu, Feb 16, 2012 at 12:02, Will Drewry <wad@chromium.org> wrote: >> Adds a new return value to seccomp filters that triggers a SIGTRAP to be delivered with the new TRAP_SECCOMP si_code. >> >> This allows in-process system call emulation -- including just specifying an errno or cleanly dumping core -- rather than just dying. > > SIGTRAP might not be the ideal choice of signal number, as it can make > it very difficult to debug the program in gdb. Other than that, I love > this feature. It'll significantly simplify the code that we have in > Chrome. > Sounds like SIGSYS to me. -hpa
On 02/16/2012 12:42 PM, Will Drewry wrote: > On Thu, Feb 16, 2012 at 2:24 PM, Markus Gutschke <markus@chromium.org> wrote: >> SIGTRAP might not be the ideal choice of signal number, as it can make it >> very difficult to debug the program in gdb. > > True enough. In theory, we could use the lower 16-bits of the return > value to let the bpf program set a signal, but not all signals are > masked synchronous and those that are probably get gdb's attention, > just not a severely :) (ILL, SEGV, BUS, TRAP, FPE). Perhaps SIGILL is > a logically appropriate option -- or letting the api user decide from > the SYNCHRONOUS_MASK set. I'm open to whatever makes sense, though. > (I wasn't even sure if it was kosher to add a new TRAP_SECCOMP value.) > There is a standard signal for this -- SIGSYS -- which happens to be currently unused in Linux. -hpa
On Thu, Feb 16, 2012 at 3:28 PM, H. Peter Anvin <hpa@zytor.com> wrote: > On 02/16/2012 12:42 PM, Will Drewry wrote: >> On Thu, Feb 16, 2012 at 2:24 PM, Markus Gutschke <markus@chromium.org> wrote: >>> SIGTRAP might not be the ideal choice of signal number, as it can make it >>> very difficult to debug the program in gdb. >> >> True enough. In theory, we could use the lower 16-bits of the return >> value to let the bpf program set a signal, but not all signals are >> masked synchronous and those that are probably get gdb's attention, >> just not a severely :) (ILL, SEGV, BUS, TRAP, FPE). Perhaps SIGILL is >> a logically appropriate option -- or letting the api user decide from >> the SYNCHRONOUS_MASK set. I'm open to whatever makes sense, though. >> (I wasn't even sure if it was kosher to add a new TRAP_SECCOMP value.) >> > > There is a standard signal for this -- SIGSYS -- which happens to be > currently unused in Linux. Awesome. I'll respin using that. -- To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
diff --git a/arch/Kconfig b/arch/Kconfig index 3f3052b..a01c151 100644 --- a/arch/Kconfig +++ b/arch/Kconfig @@ -203,10 +203,10 @@ config HAVE_ARCH_SECCOMP_FILTER bool help This symbol should be selected by an architecure if it provides - asm/syscall.h, specifically syscall_get_arguments() and - syscall_set_return_value(). Additionally, its system call - entry path must respect a return value of -1 from - __secure_computing_int() and/or secure_computing(). + asm/syscall.h, specifically syscall_get_arguments(), + syscall_set_return_value(), and syscall_rollback(). + Additionally, its system call entry path must respect a return + value of -1 from __secure_computing_int() and/or secure_computing(). config SECCOMP_FILTER def_bool y diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h index 0dd4e87..a6c51a6 100644 --- a/include/asm-generic/siginfo.h +++ b/include/asm-generic/siginfo.h @@ -207,7 +207,8 @@ typedef struct siginfo { #define TRAP_TRACE (__SI_FAULT|2) /* process trace trap */ #define TRAP_BRANCH (__SI_FAULT|3) /* process taken branch trap */ #define TRAP_HWBKPT (__SI_FAULT|4) /* hardware breakpoint/watchpoint */ -#define NSIGTRAP 4 +#define TRAP_SECCOMP (__SI_FAULT|5) /* secure computing trap */ +#define NSIGTRAP 5 /* * SIGCHLD si_codes diff --git a/include/linux/seccomp.h b/include/linux/seccomp.h index 879ece2..1be562f 100644 --- a/include/linux/seccomp.h +++ b/include/linux/seccomp.h @@ -19,6 +19,7 @@ * selects the least permissive choice. */ #define SECCOMP_RET_KILL 0x00000000U /* kill the task immediately */ +#define SECCOMP_RET_TRAP 0x00020000U /* disallow and send sigtrap */ #define SECCOMP_RET_ERRNO 0x00030000U /* returns an errno */ #define SECCOMP_RET_ALLOW 0x7fff0000U /* allow */ diff --git a/kernel/seccomp.c b/kernel/seccomp.c index 55d000d..c75485c 100644 --- a/kernel/seccomp.c +++ b/kernel/seccomp.c @@ -290,6 +290,21 @@ void copy_seccomp(struct seccomp *child, child->mode = prev->mode; child->filter = get_seccomp_filter(prev->filter); } + +/** + * seccomp_send_sigtrap - signals the task to allow in-process syscall emulation + * + * Forces a SIGTRAP with si_code of TRAP_SECCOMP. + */ +static void seccomp_send_sigtrap(void) +{ + struct siginfo info; + memset(&info, 0, sizeof(info)); + info.si_signo = SIGTRAP; + info.si_code = TRAP_SECCOMP; + info.si_addr = (void __user *)KSTK_EIP(current); + force_sig_info(SIGTRAP, &info, current); +} #endif /* CONFIG_SECCOMP_FILTER */ /* @@ -343,6 +358,11 @@ int __secure_computing_int(int this_syscall) -(action & SECCOMP_RET_DATA), 0); return -1; + case SECCOMP_RET_TRAP: + /* Show the handler the original registers. */ + syscall_rollback(current, task_pt_regs(current)); + seccomp_send_sigtrap(); + return -1; case SECCOMP_RET_ALLOW: return 0; case SECCOMP_RET_KILL:
Adds a new return value to seccomp filters that triggers a SIGTRAP to be delivered with the new TRAP_SECCOMP si_code. This allows in-process system call emulation -- including just specifying an errno or cleanly dumping core -- rather than just dying. Supporting this change requires that secure_computing returns a value. This change adds an int return value and creates a new __secure_computing_int and deprecates the old __secure_computing call. This allows for piecemeal arch updating using HAVE_ARCH_SECCOMP_FILTER. (If -1 is returned, the system call must be skipped.) Note, the addition of TRAP_SECCOMP may not be appropriate. There are GNU specific extensions in place (e.g., TRAP_HWBKPT), but I'm not sure how sacred the definitions are. If it would be preferable to add a brand new si_code independent of the TRAP_* or use the unused si_errno (with ENOSYS), or do something totally different, please let me know! v8: - clean up based on changes to dependent patches v7: - introduction Signed-off-by: Will Drewry <wad@chromium.org> --- arch/Kconfig | 8 ++++---- include/asm-generic/siginfo.h | 3 ++- include/linux/seccomp.h | 1 + kernel/seccomp.c | 20 ++++++++++++++++++++ 4 files changed, 27 insertions(+), 5 deletions(-)