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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
