Message-ID: <55CD3382.5070506@list.ru>
Date:	Fri, 14 Aug 2015 03:17:06 +0300
From:	Stas Sergeev <stsp@...t.ru>
To:	Andy Lutomirski <luto@...capital.net>
Cc:	Linus Torvalds <torvalds@...ux-foundation.org>,
	Raymond Jennings <shentino@...il.com>,
	Cyrill Gorcunov <gorcunov@...il.com>,
	Pavel Emelyanov <xemul@...allels.com>,
	Linux kernel <linux-kernel@...r.kernel.org>
Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered
 to 64-bit programs breaks dosemu

14.08.2015 03:05, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev <stsp@...t.ru> wrote:
>> 14.08.2015 02:00, Andy Lutomirski пишет:
>>
>>> On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev <stsp@...t.ru> wrote:
>>>> 14.08.2015 01:29, Andy Lutomirski пишет:
>>>>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev <stsp@...t.ru> 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?
For example because you can as well do:
prctl(ARCH_SET_SIGNAL_SS, 0)
which will mean "restore ss in sighandler to its current value",
and this will fix the regression right here right now, without
any lar heuristic, and will keep the correct behaviour of always
restoring ss for those who need that.

>    ISTM user code should do this itself with a
> little bit of asm unless there's a good reason it wouldn't work.
Any example of that asm?

I can even code up the ARCH_SET_SIGNAL_SS patch if you want,
it seems absolutely trivial, much simpler than the aforementioned asm,
much simpler than the patches you propose.
So my question is more like "why not", rather than "why".
Just because it is simple and clean, IMHO.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/

Powered by blists - more mailing lists