Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751862AbbHMLI5 (ORCPT ); Thu, 13 Aug 2015 07:08:57 -0400 Received: from smtp17.mail.ru ([94.100.176.154]:40813 "EHLO smtp17.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751345AbbHMLIz (ORCPT ); Thu, 13 Aug 2015 07:08:55 -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> <55CB9697.1050602@list.ru> <55CBA4CE.1040108@list.ru> <55CBA909.3020306@list.ru> <55CBB053.7050803@list.ru> <55CBB2CC.9090600@list.ru> <55CBBFB9.1080201@list.ru> Cc: X86 ML , Linux kernel From: Stas Sergeev Message-ID: <55CC7AC0.3000306@list.ru> Date: Thu, 13 Aug 2015 14:08:48 +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 Content-Length: 5123 Lines: 101 13.08.2015 01:00, Andy Lutomirski пишет: > On Wed, Aug 12, 2015 at 2:50 PM, Stas Sergeev wrote: >> 13.08.2015 00:37, Andy Lutomirski пишет: >> >>> On Wed, Aug 12, 2015 at 1:55 PM, Stas Sergeev wrote: >>>> 12.08.2015 23:47, Andy Lutomirski пишет: >>>> >>>>> On Wed, Aug 12, 2015 at 1:45 PM, Stas Sergeev wrote: >>>>>> 12.08.2015 23:28, Andy Lutomirski пишет: >>>>>> >>>>>>> On Wed, Aug 12, 2015 at 1:14 PM, Stas Sergeev wrote: >>>>>>>> 12.08.2015 23:01, Andy Lutomirski пишет: >>>>>>>>> On Wed, Aug 12, 2015 at 12:55 PM, Stas Sergeev wrote: >>>>>>>>>> 12.08.2015 22:20, Andy Lutomirski пишет: >>>>>>>>>>> current kernels, it stays switched. If we change this, it won't >>>>>>>>>>> stay >>>>>>>>>>> switched. Even ignoring old ABI, it's not really clear to me what >>>>>>>>>>> the >>>>>>>>>>> right thing to do is. >>>>>>>>>> There can be the following cases: >>>>>>>>>> - switch_userspace_thread() switches fs to non-zero selector >>>>>>>>>> - switch_userspace_thread() switches the fs base via syscall >>>>>>>>>> - switch_userspace_thread() switches fs in sigcontext >>>>>>>>>> - switch_userspace_thread() switches fs_base in sigcontext (???) >>>>>>>>>> What exactly case do you have in mind? >>>>>>>>>> I'd say, the way x86_32 is doing things - is good, but the >>>>>>>>>> bases... perhaps, in ideal world, they should be a part of >>>>>>>>>> the sigcontext as well? >>>>>>>>> Any of the above. What do you want the kernel to do, and how does >>>>>>>>> the >>>>>>>>> kernel know you want to do that? The kernel has to pick *some* >>>>>>>>> semantics here. >>>>>>>> Assuming the bases are made the part of a sigcontext, >>>>>>>> I'd say there would be no ambiguities remained at all: >>>>>>>> whatever you change in a sigcontext, will be "applied" by >>>>>>>> the sigreturn(). Whatever you put in the registers >>>>>>>> (either segregs or MSRs), is valid until sigreturn(), then >>>>>>>> forgotten forever. >>>>>>>> The mess only comes in when some things are part of >>>>>>>> sigcontext and some are not. But if you have _all_ things >>>>>>>> accessable in sigcontext, then the user has a way of expressing >>>>>>>> his needs very clearly: he'll either touch sigcontext or direct >>>>>>>> values, depending on what he need. >>>>>>>> >>>>>>>> Is this right? >>>>>>> Maybe, except that doing this might break existing code (Wine and Java >>>>>>> come to mind). I'm not really sure. >>>>>> Yes, but that's why I was talking about some new >>>>>> flag. Maybe a new sigaction() flag? Or something else that >>>>>> will allow the user to request explicitly the new handling >>>>>> where the things are all switched by the kernel. Then >>>>>> the old programs that don't use that flag, will remain >>>>>> unaffected. I realize this may be a lot of work... But please >>>>>> note that there will be no more a chance like this one, >>>>>> when things are already badly broken. :) >>>>> I think that, with my patch, we get the best of both worlds. We keep >>>>> the old behavior in cases where it would work, and we switch to the >>>>> new behavior in cases where the old behavior would result in killing >>>>> the task. >>>> But I mean also fs/TLS. >>>> There is a chance now to fix things for good, all at once. :) >>>> With such an ss patch applied to stable, there will be no more >>>> such a chance ever. What's your opinion on the possibility of >>>> fixing the TLS problem? >>>> Also I am not sure about the sigreturn()'s detection: is it >>>> a subject of the subsequent patch, or you dropped an idea? >>> I think these things shouldn't be conflated. If we can fix it >>> transparently (i.e. if my patch works), then I think we should do >>> something like my patch. >> 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. Unfortunately, this doesn't help. I made a simple patch that checks the kernel version: https://github.com/stsp/dosemu2/commit/098413ef8de98972ca795e078351ae9f3cc07ffe but iret is still used when switching to DOS code from dosemu code, rather than from signal handler. So espfix64 doesn't help much. I guess the only real solution to this would be to "rewrite" dosemu so that the DOS code is run in a clone(CLONE_VM) separate process... -- 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/