linux-arm-kernel.lists.infradead.org archive mirror
 help / color / mirror / Atom feed
* [PATCH] Ensure predictable endian state on signal handler entry
@ 2011-02-14 20:02 Russell King - ARM Linux
  2011-02-15 10:37 ` Dave Martin
  0 siblings, 1 reply; 2+ messages in thread
From: Russell King - ARM Linux @ 2011-02-14 20:02 UTC (permalink / raw)
  To: linux-arm-kernel

Ensure a predictable endian state when entering signal handlers.  This
avoids programs which use SETEND to momentarily switch their endian
state from having their signal handlers entered with an unpredictable
endian state.

Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
--

 arch/arm/kernel/signal.c |    4 +++-
 1 files changed, 3 insertions(+), 1 deletions(-)

diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
index 907d5a6..abaf844 100644
--- a/arch/arm/kernel/signal.c
+++ b/arch/arm/kernel/signal.c
@@ -474,7 +474,9 @@ setup_return(struct pt_regs *regs, struct k_sigaction *ka,
 	unsigned long handler = (unsigned long)ka->sa.sa_handler;
 	unsigned long retcode;
 	int thumb = 0;
-	unsigned long cpsr = regs->ARM_cpsr & ~PSR_f;
+	unsigned long cpsr = regs->ARM_cpsr & ~(PSR_f | PSR_E_BIT);
+
+	cpsr |= PSR_ENDSTATE;
 
 	/*
 	 * Maybe we need to deliver a 32-bit signal to a 26-bit task.

^ permalink raw reply related	[flat|nested] 2+ messages in thread

* [PATCH] Ensure predictable endian state on signal handler entry
  2011-02-14 20:02 [PATCH] Ensure predictable endian state on signal handler entry Russell King - ARM Linux
@ 2011-02-15 10:37 ` Dave Martin
  0 siblings, 0 replies; 2+ messages in thread
From: Dave Martin @ 2011-02-15 10:37 UTC (permalink / raw)
  To: linux-arm-kernel

On Mon, Feb 14, 2011 at 08:02:22PM +0000, Russell King - ARM Linux wrote:
> Ensure a predictable endian state when entering signal handlers.  This
> avoids programs which use SETEND to momentarily switch their endian
> state from having their signal handlers entered with an unpredictable
> endian state.
> 
> Signed-off-by: Russell King <rmk+kernel@arm.linux.org.uk>
> --
> 
>  arch/arm/kernel/signal.c |    4 +++-
>  1 files changed, 3 insertions(+), 1 deletions(-)
> 
> diff --git a/arch/arm/kernel/signal.c b/arch/arm/kernel/signal.c
> index 907d5a6..abaf844 100644
> --- a/arch/arm/kernel/signal.c
> +++ b/arch/arm/kernel/signal.c
> @@ -474,7 +474,9 @@ setup_return(struct pt_regs *regs, struct k_sigaction *ka,
>  	unsigned long handler = (unsigned long)ka->sa.sa_handler;
>  	unsigned long retcode;
>  	int thumb = 0;
> -	unsigned long cpsr = regs->ARM_cpsr & ~PSR_f;
> +	unsigned long cpsr = regs->ARM_cpsr & ~(PSR_f | PSR_E_BIT);
> +
> +	cpsr |= PSR_ENDSTATE;
>  
>  	/*
>  	 * Maybe we need to deliver a 32-bit signal to a 26-bit task.
> 
> _______________________________________________
> linux-arm-kernel mailing list
> linux-arm-kernel at lists.infradead.org
> http://lists.infradead.org/mailman/listinfo/linux-arm-kernel

Looks sensible to me.

Acked-by: Dave Martin <dave.martin@linaro.org>

Only tested it with little-endian, but it's enough to make my silly
test program not segfault.  (Without your patch, it definitely does...)

#include <stdio.h>
#include <signal.h>
#include <string.h>
#include <unistd.h>

static void handler(int n)
{
	unsigned long cpsr;
#define FORMAT "handler: CPSR = 0x%08lX\n"
	char buf[sizeof FORMAT - 5 + 8];

	asm ("mrs %0, CPSR" : "=r" (cpsr));

	snprintf(buf, sizeof buf, FORMAT, cpsr);

	write(STDOUT_FILENO, buf, strlen(buf));
}

int main(void)
{
	signal(SIGINT, handler);

	asm volatile (
	"0:	setend	be\n\t"
	"	b 0b"
	);
}

Cheers
---Dave

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2011-02-15 10:37 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-02-14 20:02 [PATCH] Ensure predictable endian state on signal handler entry Russell King - ARM Linux
2011-02-15 10:37 ` Dave Martin

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).