linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
From: Dave Martin <Dave.Martin@arm.com>
To: Peter Collingbourne <pcc@google.com>
Cc: Linux ARM <linux-arm-kernel@lists.infradead.org>,
	linux-parisc@vger.kernel.org,
	Catalin Marinas <catalin.marinas@arm.com>,
	Kevin Brodsky <kevin.brodsky@arm.com>,
	Oleg Nesterov <oleg@redhat.com>,
	"James E.J. Bottomley" <James.Bottomley@HansenPartnership.com>,
	Kostya Serebryany <kcc@google.com>,
	"Eric W. Biederman" <ebiederm@xmission.com>,
	Andrey Konovalov <andreyknvl@google.com>,
	David Spickett <david.spickett@linaro.org>,
	Vincenzo Frascino <vincenzo.frascino@arm.com>,
	Will Deacon <will@kernel.org>,
	Evgenii Stepanov <eugenis@google.com>,
	Richard Henderson <rth@twiddle.net>
Subject: Re: [PATCH v9 3/6] signal: clear non-uapi flag bits when passing/returning sa_flags
Date: Wed, 19 Aug 2020 11:39:48 +0100	[thread overview]
Message-ID: <20200819103948.GF6642@arm.com> (raw)
In-Reply-To: <68bd2d6544fb17bbe2fb90862e28ec38e079549a.1597720138.git.pcc@google.com>

On Mon, Aug 17, 2020 at 08:33:48PM -0700, Peter Collingbourne wrote:

Nit: please say what the patch does.  Subject line should summarise
what is done, but should not add new information that is not present in
the description proper.

(Same for all the other patches.)

> This allows userspace to detect missing support for flag bits and
> allows the kernel to use non-uapi bits internally, as we are already
> doing in arch/x86 for two flag bits. Now that this change is in
> place, we no longer need the code in arch/x86 that was hiding these
> bits from userspace, so remove it.
> 
> Signed-off-by: Peter Collingbourne <pcc@google.com>
> ---
> View this change in Gerrit: https://linux-review.googlesource.com/q/I35aab6f5be932505d90f3b3450c083b4db1eca86
> 
>  arch/arm/include/asm/signal.h    |  4 ++++
>  arch/parisc/include/asm/signal.h |  4 ++++
>  arch/x86/kernel/signal_compat.c  |  7 -------
>  include/linux/signal_types.h     | 12 ++++++++++++
>  kernel/signal.c                  | 10 ++++++++++
>  5 files changed, 30 insertions(+), 7 deletions(-)
> 
> diff --git a/arch/arm/include/asm/signal.h b/arch/arm/include/asm/signal.h
> index 65530a042009..d1070a783993 100644
> --- a/arch/arm/include/asm/signal.h
> +++ b/arch/arm/include/asm/signal.h
> @@ -17,6 +17,10 @@ typedef struct {
>  	unsigned long sig[_NSIG_WORDS];
>  } sigset_t;
>  
> +#define SA_UAPI_FLAGS                                                          \
> +	(SA_NOCLDSTOP | SA_NOCLDWAIT | SA_SIGINFO | SA_THIRTYTWO |             \
> +	 SA_RESTORER | SA_ONSTACK | SA_RESTART | SA_NODEFER | SA_RESETHAND)
> +

I wonder whether all these per-arch definitions will tend to bitrot when
people add new common flags.

Can we have a common definition for the common bits, and just add the
extra arch-specific ones here?


Also, I wonder whether we should avoid the "SA_" prefix here.  Maybe
UAPI_SA_FLAGS?

>  #define __ARCH_HAS_SA_RESTORER
>  
>  #include <asm/sigcontext.h>
> diff --git a/arch/parisc/include/asm/signal.h b/arch/parisc/include/asm/signal.h
> index 715c96ba2ec8..ad06e14f6e8a 100644
> --- a/arch/parisc/include/asm/signal.h
> +++ b/arch/parisc/include/asm/signal.h
> @@ -21,6 +21,10 @@ typedef struct {
>  	unsigned long sig[_NSIG_WORDS];
>  } sigset_t;
>  
> +#define SA_UAPI_FLAGS                                                          \
> +	(SA_ONSTACK | SA_RESETHAND | SA_NOCLDSTOP | SA_SIGINFO | SA_NODEFER |  \
> +	 SA_RESTART | SA_NOCLDWAIT | _SA_SIGGFAULT)
> +
>  #include <asm/sigcontext.h>
>  
>  #endif /* !__ASSEMBLY */
> diff --git a/arch/x86/kernel/signal_compat.c b/arch/x86/kernel/signal_compat.c
> index 9ccbf0576cd0..c599013ae8cb 100644
> --- a/arch/x86/kernel/signal_compat.c
> +++ b/arch/x86/kernel/signal_compat.c
> @@ -165,16 +165,9 @@ void sigaction_compat_abi(struct k_sigaction *act, struct k_sigaction *oact)
>  {
>  	signal_compat_build_tests();
>  
> -	/* Don't leak in-kernel non-uapi flags to user-space */
> -	if (oact)
> -		oact->sa.sa_flags &= ~(SA_IA32_ABI | SA_X32_ABI);
> -
>  	if (!act)
>  		return;
>  
> -	/* Don't let flags to be set from userspace */
> -	act->sa.sa_flags &= ~(SA_IA32_ABI | SA_X32_ABI);
> -
>  	if (in_ia32_syscall())
>  		act->sa.sa_flags |= SA_IA32_ABI;
>  	if (in_x32_syscall())
> diff --git a/include/linux/signal_types.h b/include/linux/signal_types.h
> index f8a90ae9c6ec..e792f29b5846 100644
> --- a/include/linux/signal_types.h
> +++ b/include/linux/signal_types.h
> @@ -68,4 +68,16 @@ struct ksignal {
>  	int sig;
>  };
>  
> +#ifndef SA_UAPI_FLAGS
> +#ifdef SA_RESTORER
> +#define SA_UAPI_FLAGS                                                          \
> +	(SA_NOCLDSTOP | SA_NOCLDWAIT | SA_SIGINFO | SA_ONSTACK | SA_RESTART |  \
> +	 SA_NODEFER | SA_RESETHAND | SA_RESTORER)
> +#else
> +#define SA_UAPI_FLAGS                                                          \
> +	(SA_NOCLDSTOP | SA_NOCLDWAIT | SA_SIGINFO | SA_ONSTACK | SA_RESTART |  \
> +	 SA_NODEFER | SA_RESETHAND)
> +#endif
> +#endif
> +
>  #endif /* _LINUX_SIGNAL_TYPES_H */
> diff --git a/kernel/signal.c b/kernel/signal.c
> index 42b67d2cea37..348b7981f1ff 100644
> --- a/kernel/signal.c
> +++ b/kernel/signal.c
> @@ -3984,6 +3984,16 @@ int do_sigaction(int sig, struct k_sigaction *act, struct k_sigaction *oact)
>  	if (oact)
>  		*oact = *k;
>  
> +	/*
> +	 * Clear unknown flag bits in order to allow userspace to detect missing
> +	 * support for flag bits and to allow the kernel to use non-uapi bits
> +	 * internally.
> +	 */
> +	if (act)
> +		act->sa.sa_flags &= SA_UAPI_FLAGS;
> +	if (oact)
> +		oact->sa.sa_flags &= SA_UAPI_FLAGS;
> +

Seems reasonable.

Cheers
---Dave

>  	sigaction_compat_abi(act, oact);
>  
>  	if (act) {
> -- 
> 2.28.0.220.ged08abb693-goog
> 
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel@lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

_______________________________________________
linux-arm-kernel mailing list
linux-arm-kernel@lists.infradead.org
http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

  reply	other threads:[~2020-08-19 10:41 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-08-18  3:33 [PATCH v9 0/6] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-08-18  3:33 ` [PATCH v9 1/6] parisc: start using signal-defs.h Peter Collingbourne
2020-08-18  3:33 ` [PATCH v9 2/6] arch: move SA_* definitions to generic headers Peter Collingbourne
2020-08-19  7:13   ` Geert Uytterhoeven
2020-08-19 22:44     ` Peter Collingbourne
2020-08-19 10:30   ` Dave Martin
2020-08-19 21:35     ` Peter Collingbourne
2020-08-18  3:33 ` [PATCH v9 3/6] signal: clear non-uapi flag bits when passing/returning sa_flags Peter Collingbourne
2020-08-19 10:39   ` Dave Martin [this message]
2020-08-19 23:39     ` Peter Collingbourne
2020-08-24 13:40       ` Dave Martin
2020-08-25  0:51         ` Peter Collingbourne
2020-08-25 14:25           ` Dave Martin
2020-08-18  3:33 ` [PATCH v9 4/6] signal: define the SA_UNSUPPORTED bit in sa_flags Peter Collingbourne
2020-08-19 14:51   ` Dave Martin
2020-08-20  0:23     ` Peter Collingbourne
2020-08-24 13:41       ` Dave Martin
2020-08-18  3:33 ` [PATCH v9 5/6] signal: define the field siginfo.si_xflags Peter Collingbourne
2020-08-19 15:40   ` Dave Martin
2020-08-20  1:37     ` Peter Collingbourne
2020-08-24 14:03       ` Dave Martin
2020-08-25  1:27         ` Peter Collingbourne
2020-08-25 14:47           ` Dave Martin
2020-08-25 20:08             ` Peter Collingbourne
2020-08-26 16:15               ` Dave Martin
2020-08-18  3:33 ` [PATCH v9 6/6] arm64: expose FAR_EL1 tag bits in siginfo Peter Collingbourne
2020-08-19 15:56   ` Dave Martin
2020-08-20  1:49     ` Peter Collingbourne
2020-08-24 14:23       ` Dave Martin
2020-08-25  2:18         ` Peter Collingbourne
2020-08-25 15:02           ` Dave Martin
2020-08-25 22:06             ` Peter Collingbourne
2020-08-26 15:32               ` Dave Martin

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=20200819103948.GF6642@arm.com \
    --to=dave.martin@arm.com \
    --cc=James.Bottomley@HansenPartnership.com \
    --cc=andreyknvl@google.com \
    --cc=catalin.marinas@arm.com \
    --cc=david.spickett@linaro.org \
    --cc=ebiederm@xmission.com \
    --cc=eugenis@google.com \
    --cc=kcc@google.com \
    --cc=kevin.brodsky@arm.com \
    --cc=linux-arm-kernel@lists.infradead.org \
    --cc=linux-parisc@vger.kernel.org \
    --cc=oleg@redhat.com \
    --cc=pcc@google.com \
    --cc=rth@twiddle.net \
    --cc=vincenzo.frascino@arm.com \
    --cc=will@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;
as well as URLs for NNTP newsgroup(s).