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

Bryan Ford
2005-10-06T15:22:43Z

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