From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751513AbbHLSz1 (ORCPT ); Wed, 12 Aug 2015 14:55:27 -0400 Received: from smtp50.i.mail.ru ([94.100.177.110]:41787 "EHLO smtp50.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750826AbbHLSzZ (ORCPT ); Wed, 12 Aug 2015 14:55:25 -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> <55CAFD9F.2070001@list.ru> <55CB7BAE.9090503@list.ru> Cc: X86 ML , Linux kernel From: Stas Sergeev Message-ID: <55CB9697.1050602@list.ru> Date: Wed, 12 Aug 2015 21:55:19 +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 12.08.2015 21:25, Andy Lutomirski пишет: >>>> https://github.com/stsp/dosemu2/commit/7898ac60d5e569964127d6cc48f592caecd20b81 >>> So the problem is that dosemu was actually hacking around the old >>> buggy behavior and thus relying on it. Grr. >> What else it could do? :( > Going back in time? Ask the kernel to fix the issue. Like this? http://www.x86-64.org/pipermail/discuss/2007-May/009913.html And this: http://www.x86-64.org/pipermail/discuss/2007-May/009923.html >>>> Good, but have you added any flag for dosemu to even know >>>> it can do this? Unless I am mistaken, you didn't. So the fix you >>>> suggest, is not easy to detect and make portable with the older >>>> kernels. Any suggestions? >>>> >>> You could probe for it directly: raise a signal, change the saved ss >>> and see what's in ss after sigreturn. >> Umm, nope. > Why not? The safest general way to detect new features is to try to use them. But this is just too many ugly code for nothing. Since it is not very urgent to use sigreturn() instead of iret, I guess I'll better wait for an API addition that will let the check possible. >>> Let me see if I can come up with a clean kernel fix. >> The check for proper sigreturn would be good. > I still don't see how sigreturn matters here. It's signal *delivery* > that's the problem. But the delivery can be easily checked with "if (ss & 4)". What remains is just a sigreturn instead of iret. > I'm thinking of having signal delivery zap ss only if the old ss looks > bogus instead of zapping it unconditionally. IOW, instead of setting > regs->ss = __USER_DS unconditionally, we'd do larl on the old regs->ss > and keep it if it's DPL 3 RW data (exp-down or otherwise) and present. I am not sure how good is this. Yes, may help for a backward-compatibility. But OTOH the 32bit kernel saves _all_ registers, including ss, which is IMHO the right thing to do in general. So as long as the things are already "broken", I wonder if the new hacks are worth the troubles. Please also see here: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631#c15 Not saving fs is a pita! > I'll have to check the precise rules in both the SDM and APM. The > idea is that we don't want IRET to fail during signal delivery, which > can happen due to a bad sigreturn or a race against modify_ldt. Well, this is a "very basic" idea, so to say. The fact that segregs are not restored, have much more consequences, and since now you already broke things, I wonder if something can be finally fixed for good... What alternatives do we have? Can we do something really brave, introduce a new sigaction flag perhaps, that will just restore all segregs for new apps, and none - for old apps? I mean the above gcc bugzilla ticket in particular - very annoying one...