Re: [PATCH] x86_64 signal handling for 64-bit apps w/ mixed 32-bit code - trivial fix

[Bryan Ford <baford@mit.edu>]

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