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

From: Andy Lutomirski
Date: Thu Aug 13 2015 - 20:06:17 EST


On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <stsp@xxxxxxx> wrote:
> 14.08.2015 02:00, 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.
>
> Hmm, how about the following:
>
> prctl(ARCH_SET_SIGNAL_FS, my_tls)
> If my_tls==NULL - use current fsbase (including one of WRFSBASE).
> If my_tls==(void)-1 - don't restore.
>
> Can this work?

Certainly, but why? ISTM user code should do this itself with a
little bit of asm unless there's a good reason it wouldn't work. A
good reason it wouldn't work is that high-performance applications
need this and an extra syscall is too slow, but IMO that would need
evidence.

--Andy


--
Andy Lutomirski
AMA Capital Management, LLC
--
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/