Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752405AbbHMKOy (ORCPT ); Thu, 13 Aug 2015 06:14:54 -0400 Received: from smtp41.i.mail.ru ([94.100.177.101]:56901 "EHLO smtp41.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751773AbbHMKOw (ORCPT ); Thu, 13 Aug 2015 06:14:52 -0400 Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Ingo Molnar , Andy Lutomirski References: <55CBA4CE.1040108@list.ru> <55CBA909.3020306@list.ru> <55CBB053.7050803@list.ru> <55CBB2CC.9090600@list.ru> <55CBBFB9.1080201@list.ru> <20150813083949.GA17091@gmail.com> Cc: X86 ML , Linux kernel , Linus Torvalds , "H. Peter Anvin" , Thomas Gleixner , Brian Gerst , Borislav Petkov , Stas Sergeev From: Stas Sergeev Message-ID: <55CC6E0E.6080904@list.ru> Date: Thu, 13 Aug 2015 13:14:38 +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: <20150813083949.GA17091@gmail.com> 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: 3928 Lines: 90 13.08.2015 11:39, Ingo Molnar пишет: > * Andy Lutomirski wrote: > >>> OK. >>> I'll try to test the patch tomorrow, but I think the sigreturn()'s >>> capability detection is still needed to easily replace the iret trampoline >>> in userspace (without generating a signal and testing by hands). >>> Can of course be done with a run-time kernel version check... >> That feature is so specialized that I think you should just probe it. >> >> void foo(...) { >> sigcontext->ss = 7; >> } >> >> modify_ldt(initialize descriptor 0); >> sigaction(SIGUSR1, foo, SA_SIGINFO); >> if (ss == 7) >> yay; >> >> Fortunately, all kernels that restore ss also have espfix64, so you >> don't need to worry about esp[31:16] corruption on those kernels >> either. >> >> I suppose we could add a new uc_flag to indicate that ss is saved and restored, >> though. Ingo, hpa: any thoughts on that? There will always be some kernel >> versions that save and restore ss but don't set the flag, though. > So this new flag would essentially be a 'the ss save/restore bug is fixed for > sure' flag, not covering old kernels that happen to have the correct behavior, > right? > > Could you please map out the range of kernel versions involved - which ones: "me too" I'll just hard-code that version info into an app - testing version is the same as testing the flag. > - 'never do the right thing' > - 'do the right thing sometimes' > - 'do the right thing always, but by accident' > - 'do the right thing always and intentionally' > > ? > > I'd hate to complicate a legacy ABI any more. My gut feeling is to let apps either > assume that the kernel works right, or probe the actual behavior. The problem is that current apps assume the kernel works _wrong_, here's the reference: http://www.x86-64.org/pipermail/discuss/2007-May/009913.html http://www.x86-64.org/pipermail/discuss/2007-May/009923.html And as such, they break. Details earlier in that thread. > Adding the flag > just makes it easy to screw certain kernel versions that would still work fine if > the app used actual probing. So I don't see the flag as an improvement. > > If your patch fixes the regression that would be a good first step. Unfortunately, the currently proposed patch puts the kernel in the category 'do the right thing sometimes' from the current 'do the right thing always and intentionally'. This helps the legacy apps to work though... I am not saying this patch should not be applied, but I'd like to discuss the alternatives a bit (although Andy already put it clear that this is likely the final decision, so I am just putting a newly CCed people into a course of events). Possibilities: 1. leave things as they are and fix dosemu instead (this is against the kernel policy to not break userspace, but I wonder how relevant dosemu is today) 2. Apply Andy's patch that does tricky sanity tests with lar, and if they pass - do not restore the right ss value. 3. Admitting the wider problem, for example TLS is also not restored: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66631 and fix everything at once, probably adding a new sigaction() flag to allow an apps to request the behaviour they need (keeping the old behaviour by default). Of course all of the above have pros and cons. 3 is a lot of work, both 1 and 2 have patches ready. > Please also send the fix in email instead of just pointing to a Git tree, so that > people can comment on it. A reference for newly CCed people: https://git.kernel.org/cgit/linux/kernel/git/luto/linux.git/commit/?h=x86/sigcontext&id=83a08d8c3f43c5524ffc0d88c0eff747716696f5 Not the prettiest possible approach, but at least should work... -- 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/