Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752871AbbHMO6v (ORCPT ); Thu, 13 Aug 2015 10:58:51 -0400 Received: from mail-oi0-f42.google.com ([209.85.218.42]:34581 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752261AbbHMO6u convert rfc822-to-8bit (ORCPT ); Thu, 13 Aug 2015 10:58:50 -0400 MIME-Version: 1.0 In-Reply-To: <55CC911D.3080607@list.ru> 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> <55CC911D.3080607@list.ru> From: Andy Lutomirski Date: Thu, 13 Aug 2015 07:58:30 -0700 Message-ID: Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu To: Stas Sergeev Cc: Ingo Molnar , X86 ML , Linux kernel , Linus Torvalds , "H. Peter Anvin" , Thomas Gleixner , Brian Gerst , Borislav Petkov , Stas Sergeev Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 2839 Lines: 81 On Thu, Aug 13, 2015 at 5:44 AM, Stas Sergeev wrote: > 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: >> >> - '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. 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. > > I've tested the patch. > It doesn't fix the problem. > It allows dosemu to save the ss the old way, but, > because dosemu doesn't save it to the sigreturn()'s-expected > place (sigcontext.__pad0), it crashes on sigreturn(). > > So the problem can't be fixed this way --> NACK to the patch. > > I may be unavailable for further testings till next week. I'm still fighting with getting DOSEMU to run at all in my VM. I must be missing something. What ends up in ss/__pad0? Wouldn't it contain whatever signal delivery put there (i.e. some valid ss value)? --Andy -- 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/