Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu

[Stas Sergeev <stsp@list.ru>]

14.08.2015 01:11, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev <stsp@list.ru> wrote:
>> 14.08.2015 00:46, Linus Torvalds пишет:
>>> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@gmail.com>
>>> wrote:
>>>> I am curious about what's supposed to happen normally on signal delivery.
>>>>
>>>> Is SS a register that's supposed to be preserved like EIP/RIP and CS when
>>>> a
>>>> signal is delivered?
>>> What exactly does "supposed" mean?
>>>
>>> On x86-64, we traditionally haven't touched SS, because it doesn't
>>> really matter in 64-bit long mode. And apparently dosemu depended on
>>> that behavior.
>>>
>>> So clearly, we're not "supposed" to save/restore it. Because reality
>>> matters a hell of a lot more than any theoretical arguments.
>> Unless you introduce some clever flag to explicitly request its restoring.
>> There is another problem as well which is that gcc assumes
>> FS base to point to TLS at function prolog. Since FS is not
>> restored too, the only suggestion I get is to write a sighandlers
>> in asm... I wonder if someone really should write a sighandler in
>> asm to restore FS base manually with a syscall.
>> So I think the reality is asking for a new flag. :)
> I still don't see how this hypothetical flag would work.
>
> The relevant task state consists of FS and the hidden FS base
> register.  If you build with -fstack-protector, GCC really wants the
> FS base register to point to the right place.  So you can't change it
> in the middle of a C function (because the prologue and epilogue will
> fail to match).
>
> 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"?