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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Fri, 14 Aug 2015 03:00:26 +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 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?
--
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/