Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu
From: Stas Sergeev
Date: Thu Aug 13 2015 - 18:51:51 EST
14.08.2015 01:29, Andy Lutomirski ÐÐÑÐÑ:
On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@xxxxxxx> wrote:
14.08.2015 01:11, Andy Lutomirski ÐÐÑÐÑ:
Now suppose you set some magic flag and jump (via sigreturn,
trampoline, whatever) into DOS code. The DOS code loads 0x7 into FS
and then gets #GP. You land in a signal handler. As far as the
kernel's concerned, the FS base register is whatever the base of LDT
entry 0 is. What else is the kernel supposed to shove in there?
The same as what happens when you do in userspace:
---
asm ("mov $0,%%fs\n");
prctl(ARCH_SET_FS, my_tls_base);
---
This was the trick I did before gcc started to use FS in prolog,
now I have to do this in asm.
But how simpler for the kernel is to do the same?
I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.
Setting selector and base is what you call an "equivalent of sigaltstack"?
Yes. sigaltstack says "hey, kernel! here's my SP for signal
handling." I think we'd need something similar to tell the kernel
what my_tls_base is. Using the most recent thing passed to
ARCH_SET_FS is no good because WRFSBASE systems might not use
ARCH_SET_FS, and we can't break DOSEMU on Ivy Bridge and newer as soon
as we enable WRFSBASE.
If someone uses WRFSBASE and wants things to be preserved
in a sighandler, he'll just not set the aforementioned flag. No regression.
Whoever wants to use that flag properly, will not use WRFSBASE,
and will use ARCH_SET_FS or set_thread_area().
What exactly breakage do you have in mind?
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/