mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: "Indan Zupancic" <indan@nul.nu>
To: "Will Drewry" <wad@chromium.org>
Cc: linux-kernel@vger.kernel.org, linux-arch@vger.kernel.org,
	linux-doc@vger.kernel.org, kernel-hardening@lists.openwall.com,
	netdev@vger.kernel.org, x86@kernel.org, arnd@arndb.de,
	davem@davemloft.net, hpa@zytor.com, mingo@redhat.com,
	oleg@redhat.com, peterz@infradead.org, rdunlap@xenotime.net,
	mcgrathr@chromium.org, tglx@linutronix.de, luto@mit.edu,
	eparis@redhat.com, serge.hallyn@canonical.com, djm@mindrot.org,
	scarybeasts@gmail.com, pmoore@redhat.com,
	akpm@linux-foundation.org, corbet@lwn.net,
	eric.dumazet@gmail.com, markus@chromium.org,
	keescook@chromium.org, "Will Drewry" <wad@chromium.org>
Subject: Re: [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous.
Date: Wed, 22 Feb 2012 09:34:42 +0100	[thread overview]
Message-ID: <9edbabb2262e3d91a7b8c75dbec03d7f.squirrel@webmail.greenhost.nl> (raw)
In-Reply-To: <1329845435-2313-7-git-send-email-wad@chromium.org>

On Tue, February 21, 2012 18:30, Will Drewry wrote:
> This change enables SIGSYS, defines _sigfields._sigsys, and adds
> x86 (compat) arch support.  _sigsys defines fields which allow
> a signal handler to receive the triggering system call number,
> the relevant AUDIT_ARCH_* value for that number, and the address
> of the callsite.
>
> To ensure that SIGSYS delivery occurs on return from the triggering
> system call, SIGSYS is added to the SYNCHRONOUS_MASK macro.  I'm
> this is enough to ensure it will be synchronous or if it is explicitly
> required to ensure an immediate delivery of the signal upon return from
> the blocked system call.
>
> The first consumer of SIGSYS would be seccomp filter.  In particular,
> a filter program could specify a new return value, SECCOMP_RET_TRAP,
> which would result in the system call being denied and the calling
> thread signaled.  This also means that implementing arch-specific
> support can be dependent upon HAVE_ARCH_SECCOMP_FILTER.

I think others said this is useful, but I don't see how. Easier
debugging compared to checking return values?

I suppose SIGSYS can be blocked, so there is no guarantee the process
will be killed.

> v10: - first version based on suggestion
>
> Suggested-by: H. Peter Anvin <hpa@zytor.com>
> Signed-off-by: Will Drewry <wad@chromium.org>
> ---
>  arch/x86/ia32/ia32_signal.c   |    4 ++++
>  arch/x86/include/asm/ia32.h   |    6 ++++++
>  include/asm-generic/siginfo.h |   18 ++++++++++++++++++
>  kernel/signal.c               |    2 +-
>  4 files changed, 29 insertions(+), 1 deletions(-)
>
> diff --git a/arch/x86/ia32/ia32_signal.c b/arch/x86/ia32/ia32_signal.c
> index 6557769..c81d2c7 100644
> --- a/arch/x86/ia32/ia32_signal.c
> +++ b/arch/x86/ia32/ia32_signal.c
> @@ -73,6 +73,10 @@ int copy_siginfo_to_user32(compat_siginfo_t __user *to, siginfo_t
> *from)
>  			switch (from->si_code >> 16) {
>  			case __SI_FAULT >> 16:
>  				break;
> +			case __SI_SYS >> 16:
> +				put_user_ex(from->si_syscall, &to->si_syscall);
> +				put_user_ex(from->si_arch, &to->si_arch);
> +				break;
>  			case __SI_CHLD >> 16:
>  				put_user_ex(from->si_utime, &to->si_utime);
>  				put_user_ex(from->si_stime, &to->si_stime);
> diff --git a/arch/x86/include/asm/ia32.h b/arch/x86/include/asm/ia32.h
> index 1f7e625..541485f 100644
> --- a/arch/x86/include/asm/ia32.h
> +++ b/arch/x86/include/asm/ia32.h
> @@ -126,6 +126,12 @@ typedef struct compat_siginfo {
>  			int _band;	/* POLL_IN, POLL_OUT, POLL_MSG */
>  			int _fd;
>  		} _sigpoll;
> +
> +		struct {
> +			unsigned int _call_addr; /* calling insn */

Why an int here, but a pointer below?

> +			int _syscall;	/* triggering system call number */
> +			unsigned int _arch;	/* AUDIT_ARCH_* of syscall */
> +		} _sigsys;
>  	} _sifields;
>  } compat_siginfo_t;
>
> diff --git a/include/asm-generic/siginfo.h b/include/asm-generic/siginfo.h
> index 0dd4e87..a83b478 100644
> --- a/include/asm-generic/siginfo.h
> +++ b/include/asm-generic/siginfo.h
> @@ -90,6 +90,13 @@ typedef struct siginfo {
>  			__ARCH_SI_BAND_T _band;	/* POLL_IN, POLL_OUT, POLL_MSG */
>  			int _fd;
>  		} _sigpoll;
> +
> +		/* SIGSYS */
> +		struct {
> +			void __user *_call_addr; /* calling insn */

Is this a user instruction pointer or a filter instruction?

> +			int _syscall;	/* triggering system call number */
> +			unsigned int _arch;	/* AUDIT_ARCH_* of syscall */
> +		} _sigsys;
>  	} _sifields;
>  } siginfo_t;
>
> @@ -116,6 +123,9 @@ typedef struct siginfo {
>  #define si_addr_lsb	_sifields._sigfault._addr_lsb
>  #define si_band		_sifields._sigpoll._band
>  #define si_fd		_sifields._sigpoll._fd
> +#define si_call_addr	_sifields._sigsys._call_addr
> +#define si_syscall	_sifields._sigsys._syscall
> +#define si_arch		_sifields._sigsys._arch
>
>  #ifdef __KERNEL__
>  #define __SI_MASK	0xffff0000u
> @@ -126,6 +136,7 @@ typedef struct siginfo {
>  #define __SI_CHLD	(4 << 16)
>  #define __SI_RT		(5 << 16)
>  #define __SI_MESGQ	(6 << 16)
> +#define __SI_SYS	(7 << 16)
>  #define __SI_CODE(T,N)	((T) | ((N) & 0xffff))
>  #else
>  #define __SI_KILL	0
> @@ -135,6 +146,7 @@ typedef struct siginfo {
>  #define __SI_CHLD	0
>  #define __SI_RT		0
>  #define __SI_MESGQ	0
> +#define __SI_SYS	0
>  #define __SI_CODE(T,N)	(N)
>  #endif
>
> @@ -232,6 +244,12 @@ typedef struct siginfo {
>  #define NSIGPOLL	6
>
>  /*
> + * SIGSYS si_codes
> + */
> +#define SYS_SECCOMP		(__SI_SYS|1)	/* seccomp triggered */
> +#define NSIGSYS	1
> +
> +/*
>   * sigevent definitions
>   *
>   * It seems likely that SIGEV_THREAD will have to be handled from
> diff --git a/kernel/signal.c b/kernel/signal.c
> index c73c428..7573819 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -160,7 +160,7 @@ void recalc_sigpending(void)
>
>  #define SYNCHRONOUS_MASK \
>  	(sigmask(SIGSEGV) | sigmask(SIGBUS) | sigmask(SIGILL) | \
> -	 sigmask(SIGTRAP) | sigmask(SIGFPE))
> +	 sigmask(SIGTRAP) | sigmask(SIGFPE) | sigmask(SIGSYS))
>
>  int next_signal(struct sigpending *pending, sigset_t *mask)
>  {
> --

Greetings,

Indan



  reply	other threads:[~2012-02-22  8:34 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-02-21 17:30 [PATCH v10 01/11] sk_run_filter: add support for custom load_pointer Will Drewry
2012-02-21 17:30 ` [PATCH v10 02/11] seccomp: kill the seccomp_t typedef Will Drewry
2012-02-21 17:30 ` [PATCH v10 03/11] asm/syscall.h: add syscall_get_arch Will Drewry
2012-02-21 18:46   ` Roland McGrath
2012-02-21 18:57     ` Will Drewry
2012-02-21 19:01     ` [PATCH v11 " Will Drewry
2012-02-21 17:30 ` [PATCH v10 04/11] arch/x86: add syscall_get_arch to syscall.h Will Drewry
2012-02-21 17:30 ` [PATCH v10 05/11] seccomp: add system call filtering using BPF Will Drewry
2012-02-22  6:32   ` H. Peter Anvin
2012-02-22 19:48     ` Will Drewry
2012-02-22  8:19   ` Indan Zupancic
2012-02-22 14:23     ` Ben Hutchings
2012-02-22 19:47       ` Will Drewry
2012-02-22 23:46         ` Indan Zupancic
2012-02-22 23:51           ` Andrew Lutomirski
2012-02-23  0:08             ` Indan Zupancic
2012-02-23  1:07             ` H. Peter Anvin
2012-02-22 23:03       ` Indan Zupancic
2012-02-22 19:47     ` Will Drewry
2012-02-22 19:53       ` H. Peter Anvin
2012-02-22 20:01         ` Will Drewry
2012-02-23  0:25       ` Indan Zupancic
2012-02-21 17:30 ` [PATCH v10 06/11] seccomp: add SECCOMP_RET_ERRNO Will Drewry
2012-02-21 22:41   ` Kees Cook
2012-02-21 22:48     ` Will Drewry
2012-02-21 17:30 ` [PATCH v10 07/11] signal, x86: add SIGSYS info and make it synchronous Will Drewry
2012-02-22  8:34   ` Indan Zupancic [this message]
2012-02-22 19:48     ` Will Drewry
2012-02-22 23:38       ` Andrew Lutomirski
2012-02-22 23:53         ` Kees Cook
2012-02-23  0:05           ` Will Drewry
2012-02-23  0:08             ` Kees Cook
2012-02-23  0:29               ` H. Peter Anvin
2012-02-23  0:50                 ` Roland McGrath
2012-02-23  1:06                   ` H. Peter Anvin
2012-02-23 17:38                     ` Roland McGrath
2012-02-23 19:26                       ` Will Drewry
2012-02-23 22:15                         ` Indan Zupancic
2012-02-23 22:33                           ` Markus Gutschke
2012-02-23 22:36                             ` Will Drewry
2012-02-27 12:32                             ` Indan Zupancic
2012-02-27 16:21                               ` Will Drewry
2012-02-23 22:34                           ` [kernel-hardening] " Will Drewry
2012-02-23 16:44                 ` Will Drewry
2012-02-23  0:11         ` Roland McGrath
2012-02-21 17:30 ` [PATCH v10 08/11] seccomp: Add SECCOMP_RET_TRAP Will Drewry
2012-02-21 17:30 ` [PATCH v10 09/11] ptrace,seccomp: Add PTRACE_SECCOMP support Will Drewry
2012-02-22 12:22   ` Indan Zupancic
2012-02-22 19:47     ` [kernel-hardening] " Will Drewry
2012-02-21 17:30 ` [PATCH v10 10/11] x86: Enable HAVE_ARCH_SECCOMP_FILTER Will Drewry
2012-02-21 17:30 ` [PATCH v10 11/11] Documentation: prctl/seccomp_filter Will Drewry
2012-02-21 23:12   ` Kees Cook
2012-02-22  3:41     ` Will Drewry

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=9edbabb2262e3d91a7b8c75dbec03d7f.squirrel@webmail.greenhost.nl \
    --to=indan@nul.nu \
    --cc=akpm@linux-foundation.org \
    --cc=arnd@arndb.de \
    --cc=corbet@lwn.net \
    --cc=davem@davemloft.net \
    --cc=djm@mindrot.org \
    --cc=eparis@redhat.com \
    --cc=eric.dumazet@gmail.com \
    --cc=hpa@zytor.com \
    --cc=keescook@chromium.org \
    --cc=kernel-hardening@lists.openwall.com \
    --cc=linux-arch@vger.kernel.org \
    --cc=linux-doc@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=luto@mit.edu \
    --cc=markus@chromium.org \
    --cc=mcgrathr@chromium.org \
    --cc=mingo@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=peterz@infradead.org \
    --cc=pmoore@redhat.com \
    --cc=rdunlap@xenotime.net \
    --cc=scarybeasts@gmail.com \
    --cc=serge.hallyn@canonical.com \
    --cc=tglx@linutronix.de \
    --cc=wad@chromium.org \
    --cc=x86@kernel.org \
    /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

all inboxes | Powered by JetHome®