Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754287AbbHMXRW (ORCPT ); Thu, 13 Aug 2015 19:17:22 -0400 Received: from smtp9.mail.ru ([94.100.181.97]:54666 "EHLO smtp9.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752135AbbHMXRV (ORCPT ); Thu, 13 Aug 2015 19:17:21 -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> <55CD1968.7070002@list.ru> <55CD1F79.2010508@list.ru> Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel From: Stas Sergeev Message-ID: <55CD257D.3020805@list.ru> Date: Fri, 14 Aug 2015 02:17:17 +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: 2634 Lines: 50 14.08.2015 02:00, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 3:51 PM, Stas Sergeev wrote: >> 14.08.2015 01:29, Andy Lutomirski пишет: >>> On Thu, Aug 13, 2015 at 3:25 PM, Stas Sergeev 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@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/