linux-kernel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Andy Lutomirski <luto@amacapital.net>
To: AKASHI Takahiro <takahiro.akashi@linaro.org>,
	wad@chromium.org, catalin.marinas@arm.com, will.deacon@arm.com,
	keescook@chromium.org
Cc: dsaxena@linaro.org, linux-arm-kernel@lists.infradead.org,
	linaro-kernel@lists.linaro.org, linux-kernel@vger.kernel.org
Subject: Re: [PATCH v5 3/3] arm64: Add seccomp support
Date: Wed, 23 Jul 2014 20:52:09 -0700	[thread overview]
Message-ID: <53D082E9.8090303@amacapital.net> (raw)
In-Reply-To: <1406020499-5537-4-git-send-email-takahiro.akashi@linaro.org>

On 07/22/2014 02:14 AM, AKASHI Takahiro wrote:
> secure_computing() should always be called first in syscall_trace_enter().
>
> If secure_computing() returns -1, we should stop further handling. Then
> that system call may eventually fail with a specified return value (errno),
> be trapped or the process itself be killed depending on loaded rules.
> In these cases, syscall_trace_enter() also returns -1, that results in
> skiping a normal syscall handling as well as syscall_trace_exit().
>
> Signed-off-by: AKASHI Takahiro <takahiro.akashi@linaro.org>
> ---
>   arch/arm64/Kconfig               |   14 ++++++++++++++
>   arch/arm64/include/asm/seccomp.h |   25 +++++++++++++++++++++++++
>   arch/arm64/include/asm/unistd.h  |    3 +++
>   arch/arm64/kernel/ptrace.c       |    5 +++++
>   4 files changed, 47 insertions(+)
>   create mode 100644 arch/arm64/include/asm/seccomp.h
>
> diff --git a/arch/arm64/Kconfig b/arch/arm64/Kconfig
> index 3a18571..eeac003 100644
> --- a/arch/arm64/Kconfig
> +++ b/arch/arm64/Kconfig
> @@ -32,6 +32,7 @@ config ARM64
>   	select HAVE_ARCH_AUDITSYSCALL
>   	select HAVE_ARCH_JUMP_LABEL
>   	select HAVE_ARCH_KGDB
> +	select HAVE_ARCH_SECCOMP_FILTER
>   	select HAVE_ARCH_TRACEHOOK
>   	select HAVE_C_RECORDMCOUNT
>   	select HAVE_DEBUG_BUGVERBOSE
> @@ -259,6 +260,19 @@ config ARCH_HAS_CACHE_LINE_SIZE
>
>   source "mm/Kconfig"
>
> +config SECCOMP
> +	bool "Enable seccomp to safely compute untrusted bytecode"
> +	---help---
> +	  This kernel feature is useful for number crunching applications
> +	  that may need to compute untrusted bytecode during their
> +	  execution. By using pipes or other transports made available to
> +	  the process as file descriptors supporting the read/write
> +	  syscalls, it's possible to isolate those applications in
> +	  their own address space using seccomp. Once seccomp is
> +	  enabled via prctl(PR_SET_SECCOMP), it cannot be disabled
> +	  and the task is only allowed to execute a few safe syscalls
> +	  defined by each seccomp mode.
> +
>   config XEN_DOM0
>   	def_bool y
>   	depends on XEN
> diff --git a/arch/arm64/include/asm/seccomp.h b/arch/arm64/include/asm/seccomp.h
> new file mode 100644
> index 0000000..c76fac9
> --- /dev/null
> +++ b/arch/arm64/include/asm/seccomp.h
> @@ -0,0 +1,25 @@
> +/*
> + * arch/arm64/include/asm/seccomp.h
> + *
> + * Copyright (C) 2014 Linaro Limited
> + * Author: AKASHI Takahiro <takahiro.akashi@linaro.org>
> + *
> + * This program is free software; you can redistribute it and/or modify
> + * it under the terms of the GNU General Public License version 2 as
> + * published by the Free Software Foundation.
> + */
> +#ifndef _ASM_SECCOMP_H
> +#define _ASM_SECCOMP_H
> +
> +#include <asm/unistd.h>
> +
> +#ifdef CONFIG_COMPAT
> +#define __NR_seccomp_read_32		__NR_compat_read
> +#define __NR_seccomp_write_32		__NR_compat_write
> +#define __NR_seccomp_exit_32		__NR_compat_exit
> +#define __NR_seccomp_sigreturn_32	__NR_compat_rt_sigreturn
> +#endif /* CONFIG_COMPAT */
> +
> +#include <asm-generic/seccomp.h>
> +
> +#endif /* _ASM_SECCOMP_H */
> diff --git a/arch/arm64/include/asm/unistd.h b/arch/arm64/include/asm/unistd.h
> index c980ab7..729c155 100644
> --- a/arch/arm64/include/asm/unistd.h
> +++ b/arch/arm64/include/asm/unistd.h
> @@ -31,6 +31,9 @@
>    * Compat syscall numbers used by the AArch64 kernel.
>    */
>   #define __NR_compat_restart_syscall	0
> +#define __NR_compat_exit		1
> +#define __NR_compat_read		3
> +#define __NR_compat_write		4
>   #define __NR_compat_sigreturn		119
>   #define __NR_compat_rt_sigreturn	173
>
> diff --git a/arch/arm64/kernel/ptrace.c b/arch/arm64/kernel/ptrace.c
> index 100d7d1..e477f6f 100644
> --- a/arch/arm64/kernel/ptrace.c
> +++ b/arch/arm64/kernel/ptrace.c
> @@ -28,6 +28,7 @@
>   #include <linux/smp.h>
>   #include <linux/ptrace.h>
>   #include <linux/user.h>
> +#include <linux/seccomp.h>
>   #include <linux/security.h>
>   #include <linux/init.h>
>   #include <linux/signal.h>
> @@ -1115,6 +1116,10 @@ asmlinkage int syscall_trace_enter(struct pt_regs *regs)
>   	saved_x0 = regs->regs[0];
>   	saved_x8 = regs->regs[8];
>
> +	if (secure_computing(regs->syscallno) == -1)
> +		/* seccomp failures shouldn't expose any additional code. */
> +		return -1;
> +

This will conflict with the fastpath stuff in Kees' tree.  (Actually, 
it's likely to apply cleanly, but fail to compile.)  The fix is trivial, 
but, given that the fastpath stuff is new, can you take a look and see 
if arm64 can use it effectively?

I suspect that the performance considerations are rather different on 
arm64 as compared to x86 (I really hope that x86 is the only 
architecture with the absurd sysret vs. iret distinction), but at least 
the seccomp_data stuff ought to help anywhere.  (It looks like there's a 
distinct fast path, too, so the two-phase thing might also be a fairly 
large win if it's supportable.)

See:

https://git.kernel.org/cgit/linux/kernel/git/kees/linux.git/log/?h=seccomp/fastpath

Also, I'll ask the usual question?  What are all of the factors other 
than nr and args that affect syscall execution?  What are the audit arch 
values?  Do they match correctly?

For example, it looks like, if arm64 adds OABI support, you'll have a 
problem.  (Note that arm currently disables audit and seccomp if OABI is 
enabled for exactly this reason.)

Do any syscall implementations care whether the user code is LE or BE? 
Are the arguments encoded the same way?

An arm-specific question: will there be any confusion as a result of the 
fact that compat syscalls seems to stick nr in w7, but arm64 puts them 
somewhere else?

--Andy

  reply	other threads:[~2014-07-24  3:52 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-22  9:14 [PATCH v5 0/3] arm64: Add seccomp support AKASHI Takahiro
2014-07-22  9:14 ` [PATCH v5 1/3] arm64: ptrace: reload a syscall number after ptrace operations AKASHI Takahiro
2014-07-22 20:15   ` Kees Cook
2014-07-23  7:03     ` AKASHI Takahiro
2014-07-23  8:25       ` Will Deacon
2014-07-23  9:09         ` AKASHI Takahiro
2014-07-23 15:13       ` Kees Cook
2014-07-24  3:54   ` Andy Lutomirski
2014-07-24  5:57     ` AKASHI Takahiro
2014-07-24 15:01       ` Andy Lutomirski
2014-07-25 10:36         ` AKASHI Takahiro
2014-07-25 11:03           ` Will Deacon
2014-07-29  6:49             ` AKASHI Takahiro
2014-07-29 13:26               ` Will Deacon
2014-07-22  9:14 ` [PATCH v5 2/3] asm-generic: Add generic seccomp.h for secure computing mode 1 AKASHI Takahiro
2014-07-24  3:40   ` Andy Lutomirski
2014-07-24  4:41     ` Kees Cook
2014-07-24  5:17       ` AKASHI Takahiro
2014-07-24 14:57         ` Andy Lutomirski
2014-07-25  8:52           ` AKASHI Takahiro
2014-07-22  9:14 ` [PATCH v5 3/3] arm64: Add seccomp support AKASHI Takahiro
2014-07-24  3:52   ` Andy Lutomirski [this message]
2014-07-24  5:40     ` AKASHI Takahiro
2014-07-24 15:00       ` Andy Lutomirski
2014-07-24 15:16         ` Catalin Marinas
2014-07-25  9:37         ` AKASHI Takahiro
2014-08-05 15:08           ` Kees Cook
2014-08-08  7:35             ` AKASHI Takahiro
2014-08-11  9:24               ` Will Deacon
2014-08-12  6:57                 ` AKASHI Takahiro
2014-08-12  9:40                   ` Will Deacon
2014-08-12 11:17                     ` AKASHI Takahiro
2014-08-15 14:33                       ` Will Deacon
2014-07-22 20:16 ` [PATCH v5 0/3] " Kees Cook
2014-07-23  7:09   ` AKASHI Takahiro
2014-07-23 15:36     ` Kees Cook

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=53D082E9.8090303@amacapital.net \
    --to=luto@amacapital.net \
    --cc=catalin.marinas@arm.com \
    --cc=dsaxena@linaro.org \
    --cc=keescook@chromium.org \
    --cc=linaro-kernel@lists.linaro.org \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=takahiro.akashi@linaro.org \
    --cc=wad@chromium.org \
    --cc=will.deacon@arm.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).