Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753955AbbHMWZv (ORCPT ); Thu, 13 Aug 2015 18:25:51 -0400 Received: from smtp44.i.mail.ru ([94.100.177.104]:52133 "EHLO smtp44.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbHMWZu (ORCPT ); Thu, 13 Aug 2015 18:25:50 -0400 Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Andy Lutomirski References: <55CA90B4.2010205@list.ru> <55CCD921.4040301@list.ru> <20150813200823.GS2059@uranus> <55CD0F29.4070604@gmail.com> <55CD13F3.1070904@list.ru> Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel From: Stas Sergeev Message-ID: <55CD1968.7070002@list.ru> Date: Fri, 14 Aug 2015 01:25:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.1.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-Mras: Ok Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2663 Lines: 56 14.08.2015 01:11, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 3:02 PM, Stas Sergeev wrote: >> 14.08.2015 00:46, Linus Torvalds пишет: >>> On Thu, Aug 13, 2015 at 2:42 PM, Raymond Jennings >>> 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/