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

[Andy Lutomirski]

On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <stsp@xxxxxxx> wrote:
> 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?

DOSEMU, when you set that flag, WRFSBASE gets enabled, and glibc's
threading library starts using WRFSBASE instead of arch_prctl.

--Andy
--
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/