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]

Message-ID: <55CD1968.7070002@list.ru>
Date:	Fri, 14 Aug 2015 01:25:44 +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 01:11, Andy Lutomirski пишет:
> On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev <stsp@...t.ru> wrote:
>> 14.08.2015 00:46, Linus Torvalds пишет:
>>> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings <shentino@...il.com>
>>> wrote:
>>>> I am curious about what's supposed to happen normally on signal delivery.
>>>>
>>>> Is SS a register that's supposed to be preserved like EIP/RIP and CS when
>>>> a
>>>> signal is delivered?
>>> What exactly does "supposed" mean?
>>>
>>> On x86-64, we traditionally haven't touched SS, because it doesn't
>>> really matter in 64-bit long mode. And apparently dosemu depended on
>>> that behavior.
>>>
>>> So clearly, we're not "supposed" to save/restore it. Because reality
>>> matters a hell of a lot more than any theoretical arguments.
>> Unless you introduce some clever flag to explicitly request its restoring.
>> There is another problem as well which is that gcc assumes
>> FS base to point to TLS at function prolog. Since FS is not
>> restored too, the only suggestion I get is to write a sighandlers
>> in asm... I wonder if someone really should write a sighandler in
>> asm to restore FS base manually with a syscall.
>> So I think the reality is asking for a new flag. :)
> I still don't see how this hypothetical flag would work.
>
> The relevant task state consists of FS and the hidden FS base
> register.  If you build with -fstack-protector, GCC really wants the
> FS base register to point to the right place.  So you can't change it
> in the middle of a C function (because the prologue and epilogue will
> fail to match).
>
> 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"?
--
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/