Date: Thu, 06 Oct 2005 11:22:11 -0400
From: Bryan Ford <baford@mit.edu>
Subject: Re: [PATCH] x86_64 signal handling for 64-bit apps w/ mixed 32-bit
 code - trivial fix
In-reply-to: <43440F80.7050403@kolumbus.fi>
To: Mika =?iso-8859-1?q?Penttil=E4?= <mika.penttila@kolumbus.fi>
Cc: linux-kernel@vger.kernel.org
Message-id: <200510061122.11994.baford@mit.edu>
Organization: Massachusetts Institute of Technology
MIME-version: 1.0
Content-type: text/plain; charset=iso-8859-1
Content-transfer-encoding: 8BIT
Content-disposition: inline
References: <200510051235.41376.baford@mit.edu> <43440F80.7050403@kolumbus.fi>
User-Agent: KMail/1.8
Sender: linux-kernel-owner@vger.kernel.org
Content-Length: 2706
Lines: 47

On Wednesday 05 October 2005 13:38, Mika Penttil? wrote:
> Bryan Ford wrote:
> >The following trivial patch fixes a bug in signal handling on x86-64: the
> >kernel currently fails to save and restore the CS and SS segment registers
> > on user-mode signal handler dispatch/return, which makes it impossible
> > for 64-bit applications to catch and handle signals properly that occur
> > while running 32-bit code fragments in compatibility mode.
> >
> >The proposed patch doesn't affect any performance-critical paths (e.g.,
> >syscall or interrupt entry/exit), and merely involves a couple more moves
> >to/from user space on signal frame setup and sigreturn.  It also doesn't
> >affect the size or shape of the sigcontext at all, since there already was
> > an (unused) slot for CS, and I've assigned the convenient __pad0 field as
> > a slot for SS.  The existing, unused slots for FS and GS remain unused
> > for now, and I don't see any urgent need to change that.  The only way
> > this might break an existing app is if the app tries to cons up its own
> > signal frame (not generated by the kernel) and pass it to sigreturn, but
> > this is presumably a no-no anyway.
>
> What about the opposite? Are there things that would break if the app
> depends on compatibility mode signal handler?

If you're thinking about 32-bit compatibility mode apps, this patch doesn't 
affect them at all, because signal handling for 32-bit apps is already 
handled by completely separate code paths (in arch/x86_64/ia32/ia32_signal.c 
instead of arch/x86_64/kernel/signal.c).  And note that the 32-bit ABI's 
signal handling code path already saves the CS and SS properly, in exactly 
the same way as my proposed patch does for the 64-bit ABI; my patch 
effectively just brings the two in line with each other.

There is already no way for a 64-bit app to register and use a 
compatibility-mode signal handler: the kernel's signal handling code path for 
the 64-bit ABI always sets up a signal handling frame assuming that the 
signal handler will be 64-bit, and I see no reason this should be changed.  I 
would merely like it to be possible for a 64-bit app to run snippets of 
32-bit code when it needs to, and be able to catch signals that may occur 
while running that 32-bit code, without immediately dying a horrible flaming 
death as it does now because of the kernel trying to run a 64-bit signal 
handler with a 32-bit code segment still loaded.

Cheers,
Bryan
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/