From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754288AbbHNARR (ORCPT ); Thu, 13 Aug 2015 20:17:17 -0400 Received: from smtp5.mail.ru ([94.100.179.24]:36050 "EHLO smtp5.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753153AbbHNARP (ORCPT ); Thu, 13 Aug 2015 20:17:15 -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> <55CD2F9A.9040300@list.ru> Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel From: Stas Sergeev Message-ID: <55CD3382.5070506@list.ru> Date: Fri, 14 Aug 2015 03:17:06 +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 14.08.2015 03:05, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 5:00 PM, Stas Sergeev wrote: >> 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. >> Hmm, how about the following: >> >> prctl(ARCH_SET_SIGNAL_FS, my_tls) >> If my_tls==NULL - use current fsbase (including one of WRFSBASE). >> If my_tls==(void)-1 - don't restore. >> >> Can this work? > Certainly, but why? For example because you can as well do: prctl(ARCH_SET_SIGNAL_SS, 0) which will mean "restore ss in sighandler to its current value", and this will fix the regression right here right now, without any lar heuristic, and will keep the correct behaviour of always restoring ss for those who need that. > ISTM user code should do this itself with a > little bit of asm unless there's a good reason it wouldn't work. Any example of that asm? I can even code up the ARCH_SET_SIGNAL_SS patch if you want, it seems absolutely trivial, much simpler than the aforementioned asm, much simpler than the patches you propose. So my question is more like "why not", rather than "why". Just because it is simple and clean, IMHO.