From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751677AbbHLVuz (ORCPT ); Wed, 12 Aug 2015 17:50:55 -0400 Received: from smtp47.i.mail.ru ([94.100.177.107]:39969 "EHLO smtp47.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751084AbbHLVuy (ORCPT ); Wed, 12 Aug 2015 17:50:54 -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> Cc: X86 ML , Linux kernel From: Stas Sergeev Message-ID: <55CBBFB9.1080201@list.ru> Date: Thu, 13 Aug 2015 00:50:49 +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 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...