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 for Android: free password hash cracker in your pocket

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

Date:	Thu, 13 Aug 2015 15:11:31 -0700
From:	Andy Lutomirski <luto@...capital.net>
To:	Stas Sergeev <stsp@...t.ru>
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

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?

I think that making this work fully in the kernel would require a
full-blown FS equivalent of sigaltstack, and that seems like overkill.

Now, if it turns out that Oracle or whoever wants to write a JVM that
uses WRFSBASE but still handles signals using standard C signal
handlers, they're going to have the same problem.  They, too, could
fix it in libc, or someone could come up with an in-kernel mechanism
that gets enabled at the same time as WRFSBASE and is careful not to
break existing code.

I really think that we want to have a single, coherent change whenever
WRFSBASE and WRGSBASE get enabled that covers all the bases.  None of
the patch sets so far have done that.  But this cuts both ways: I
don't think we should change FS and GS behavior in signal handlers
until we are confident that we know what's happening with the FSGSBASE
instructions.

--Andy
--
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/