[uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15]

[uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15]

[Paolo 'Blaisorblade' Giarrusso]

From: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>

The problems in this area came to light while fixing a compile failure with
GCC 4, in commit bcb01b8a67476e6f748086e626df8424cc27036d. I went comparing this
code with x86_64 frame construction (which we should ABI compatible with) and
resync'ed the code a bit.

It isn't yet perfect, because we don't yet save floating point context. But that
will come later. Additionally, there's a potential problem since RED zones will
alternate stacks are used, unlike x86_64, so more stack space (128 bytes more)
is used. But this shouldn't be a problem.
Instead, having no red zone (like x86_64) will cause problems when a new signal
is delivered on the same alternate stack as one which is being handled, (since
GCC will follow the ABI and place data in the red zone in the handler for the
first delivered signal).

Please give a critical eye, even because things currently have no reported
misbehaviour, and this code is complex enough.

CC: Andi Kleen <ak@suse.de>
Signed-off-by: Paolo 'Blaisorblade' Giarrusso <blaisorblade@yahoo.it>
---

 arch/um/sys-x86_64/signal.c |   19 ++++++++++++++++---
 1 files changed, 16 insertions(+), 3 deletions(-)

diff --git a/arch/um/sys-x86_64/signal.c b/arch/um/sys-x86_64/signal.c
index a4c46a8..7e3952a 100644
--- a/arch/um/sys-x86_64/signal.c
+++ b/arch/um/sys-x86_64/signal.c
@@ -176,6 +176,7 @@ struct rt_sigframe
 
 #define round_down(m, n) (((m) / (n)) * (n))
 
+/* Taken from arch/x86_64/kernel/signal.c:setup_rt_frame(). */
 int setup_signal_stack_si(unsigned long stack_top, int sig,
 			  struct k_sigaction *ka, struct pt_regs * regs,
 			  siginfo_t *info, sigset_t *set)
@@ -186,9 +187,21 @@ int setup_signal_stack_si(unsigned long 
 	int err = 0;
 	struct task_struct *me = current;
 
-	frame = (struct rt_sigframe __user *)
-		round_down(stack_top - sizeof(struct rt_sigframe), 16) - 8;
-        frame = (struct rt_sigframe *) ((unsigned long) frame - 128);
+	/* Leave space on the stack for the Red Zone, and for saving FP
+	 * registers, even if this doesn't happen. We don't have a way to test
+	 * used_math(), so we do that inconditionally.
+	 *
+	 * XXX: RED-PEN: currently, we're using a Red Zone also for any
+	 * alternate stack set up by sigaltstack(), which x86-64 doesn't do
+	 * (because there shouldn't be any code executing there). This could
+	 * cause failures if user setup a too little alternate stack.*/
+
+        fp = (struct _fpstate *) round_down(stack_top - 128 -
+				sizeof(struct _fpstate), 16);
+
+	/* Now leave the space for the rest of signal frame. */
+	frame = (void __user *) round_down((unsigned long) fp -
+			sizeof(struct rt_sigframe), 16) - 8;
 
 	if (!access_ok(VERIFY_WRITE, fp, sizeof(struct _fpstate)))
 		goto out;


_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15]

[Andi Kleen]

> It isn't yet perfect, because we don't yet save floating point context. But
> that will come later. Additionally, there's a potential problem since RED
> zones will alternate stacks are used, unlike x86_64, so more stack space
> (128 bytes more) is used. But this shouldn't be a problem.
> Instead, having no red zone (like x86_64) 

x86-64 has a red zone. Is your description confused or your code?

-Andi



_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15]

[Blaisorblade]

On Sunday 04 June 2006 21:06, Andi Kleen wrote:
> > It isn't yet perfect, because we don't yet save floating point context.
> > But that will come later. Additionally, there's a potential problem since
> > RED zones will alternate stacks are used, unlike x86_64, so more stack
> > space (128 bytes more) is used. But this shouldn't be a problem.
> > Instead, having no red zone (like x86_64)
>
> x86-64 has a red zone.

On the alternate stack too? The comment in the below code confused me... even 
if when nesting signal frames sas_ss_flags(rsp) should be 0 and so the 
redzone will be used.
The below "RED-PEN" comment is probably wrong then... or not?

arch/x86_64/kernel/signal.c:
        /* RED-PEN: redzone on that stack? */
        if (ka->sa.sa_flags & SA_ONSTACK) {
                if (sas_ss_flags(rsp) == 0)
                        rsp = current->sas_ss_sp + current->sas_ss_size;
        }
> Is your description confused or your code? 
Sorry for the ambiguity and typos in the desc.
-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade (Skype ID "PaoloGiarrusso", ICQ 215621894)
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15]

[Andi Kleen]

On Monday 05 June 2006 13:06, Blaisorblade wrote:
> On Sunday 04 June 2006 21:06, Andi Kleen wrote:
> > > It isn't yet perfect, because we don't yet save floating point context.
> > > But that will come later. Additionally, there's a potential problem since
> > > RED zones will alternate stacks are used, unlike x86_64, so more stack
> > > space (128 bytes more) is used. But this shouldn't be a problem.
> > > Instead, having no red zone (like x86_64)
> >
> > x86-64 has a red zone.
> 
> On the alternate stack too? 

No, there not.

> The comment in the below code confused me... even  
> if when nesting signal frames sas_ss_flags(rsp) should be 0 and so the 
> redzone will be used.
> The below "RED-PEN" comment is probably wrong then... or not?
> 
> arch/x86_64/kernel/signal.c:
>         /* RED-PEN: redzone on that stack? */

It's bogus because the alternative stack cannot be nested. I will remove it.



_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel

Re: [uml-devel] [PATCH] uml: fix signal code x86-64 [for 2.6.15]

[Blaisorblade]

On Tuesday 06 June 2006 01:39, Andi Kleen wrote:
> On Monday 05 June 2006 13:06, Blaisorblade wrote:
> > On Sunday 04 June 2006 21:06, Andi Kleen wrote:
> > > > It isn't yet perfect, because we don't yet save floating point
> > > > context. But that will come later. Additionally, there's a potential
> > > > problem since RED zones will alternate stacks are used, unlike
> > > > x86_64, so more stack space (128 bytes more) is used. But this
> > > > shouldn't be a problem. Instead, having no red zone (like x86_64)
> > >
> > > x86-64 has a red zone.
> >
> > On the alternate stack too?

> No, there not.

It has a redzone if a new signal handler is invoked.

> > The comment in the below code confused me... even
> > if when nesting signal frames sas_ss_flags(rsp) should be 0 and so the
> > redzone will be used.
> > The below "RED-PEN" comment is probably wrong then... or not?
> >
> > arch/x86_64/kernel/signal.c:
> >         /* RED-PEN: redzone on that stack? */
>
> It's bogus because the alternative stack cannot be nested. I will remove
> it.

No, it's bogus because if we're already on the alternate stack sas_ss_flags() 
won't return 0, but stacks can be nested (in that case the default path will 
correctly setup a red zone).

From man sigaltstack:
Functions called from a signal handler executing on an alternate signal stack 
will also use the alternate signal stack. (This also applies to  any  
handlers invoked for  other  signals  while the process is executing on the 
alternate signal stack.)

-- 
Inform me of my mistakes, so I can keep imitating Homer Simpson's "Doh!".
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade

Chiacchiera con i tuoi amici in tempo reale! 
 http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com 



-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
User-mode-linux-devel mailing list
User-mode-linux-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-devel