From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932136AbbHMST7 (ORCPT ); Thu, 13 Aug 2015 14:19:59 -0400 Received: from smtp42.i.mail.ru ([94.100.177.102]:53552 "EHLO smtp42.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754103AbbHMST6 (ORCPT ); Thu, 13 Aug 2015 14:19:58 -0400 Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Andy Lutomirski References: <55CBA4CE.1040108@list.ru> <55CBBFB9.1080201@list.ru> <20150813083949.GA17091@gmail.com> <55CC911D.3080607@list.ru> <55CCB625.3000900@list.ru> <55CCBFDC.5000207@list.ru> <55CCC3E1.9060603@list.ru> <55CCC812.5010101@list.ru> <55CCCA78.8030806@list.ru> <55CCD054.5020600@list.ru> <55CCDB55.3040803@list.ru> Cc: Ingo Molnar , X86 ML , Linux kernel , Linus Torvalds , "H. Peter Anvin" , Thomas Gleixner , Brian Gerst , Borislav Petkov , Stas Sergeev From: Stas Sergeev Message-ID: <55CCDFC2.1000503@list.ru> Date: Thu, 13 Aug 2015 21:19:46 +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 13.08.2015 21:05, Andy Lutomirski пишет: > On Thu, Aug 13, 2015 at 11:00 AM, Stas Sergeev wrote: >> 13.08.2015 20:17, Andy Lutomirski пишет: >>> On Thu, Aug 13, 2015 at 10:13 AM, Stas Sergeev wrote: >>> >>>> Ah, I see your point now. >>>> But that's not what I mean, as it doesn't cover fs/gs, which >>>> is what Linus is looking to revert now too (I am building the >>>> testing kernels now). >>>> So you obviously don't want the flag that will control all 3 >>>> things together without any lar heuristics, but I don't understand why... >>>> Yes, your heuristic+uc_flag may work, but IMHO far from >>>> perfection and TLS problem is not covered. I can test such >>>> a patch but I don't understand why you don't want the flag >>>> that will just control all things together. >>> The fs/gs patch doesn't change anything, so there's nothing to >>> control. It just renamed fields that did nothing. (It turns out they >>> did something back before arch_prctl existed, but there's only a >>> narrow range of kernels like that, and I'm not at all convinced that >>> those kernels are ABI-compatible with modern kernels at all. This is >>> all pre-git.) >> The problem is that dosemu existed back then too. >> It still uses these fields as a place-holders. Well, this is a >> compile-time breakage only, so perhaps not as important >> as the run-time one, but still, you broke it in yet another way. > Great. What exactly is DOSEMU sticking in those fields? FS and GS of course. Saves by hands in a sighandler. > Are we now > stuck ignoring the contents in sigreturn because DOSEMU coopts them > for its own purposes? No, its just that these fields _were_ valid in times, and so, when kernel stopped using them, dosemu authors opted not to change their locations but just save things by hands. What else do you suppose could they do? Well, compile-time breakage is another thing, it can safely be ignored on your side I guess. Something like this should do: https://github.com/stsp/dosemu2/commit/4e16d83b9c7b1f9155ec0c0c125fe6f755eb719c >>> Sure, it might make sense to change TLS behavior in signals at some >>> point, but I don't think we're there yet. We need to deal with >>> fsgsbase first, and that's a *huge* can of worms. >> My point is not when to fix TLS or how. >> But you can get the flag ready, for now controlling only SS >> and fixing the regression, but it will define the course of the >> further developments. When the time will come, it will cover >> also TLS, but why not to get such a flag ready now, without >> yet fixing TLS? > I think that if we create a flag to change semantics, we shouldn't > introduce the flag and make it look like it works without actually > changing the semantics. It is more about selecting the right field for such a flag. You can select the right field now, and introduce some flag to it, like SIG_SAVE_SS or whatever. This will fix a regression. Then, when the TLS time will code, you'll just add SIG_SAVE_FS flag to the same field, so that they can be ORed.