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 02:17:17 +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.
Whoever wants to use the new flag, will need to call
prctl(ARCH_SET_FS, needed_tls) or the like, before altering FS.
"needed_tls" will be the current TLS in most cases.
This will make kernel to know what TLS should be restored in
sighandler. Yes, that's resembles sigaltstack to some degree,
but is simple? Nothing special on kernel side, and not a big
deal for the user to call prctl().
--
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/