Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752342AbbHSQa3 (ORCPT ); Wed, 19 Aug 2015 12:30:29 -0400 Received: from smtp11.mail.ru ([94.100.179.252]:35842 "EHLO smtp11.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751161AbbHSQa1 (ORCPT ); Wed, 19 Aug 2015 12:30:27 -0400 Message-ID: <55D4AF1D.2070100@list.ru> Date: Wed, 19 Aug 2015 19:30:21 +0300 From: Stas Sergeev User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:31.0) Gecko/20100101 Thunderbird/31.7.0 MIME-Version: 1.0 To: Andy Lutomirski CC: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel Subject: Re: [regression] x86/signal/64: Fix SS handling for signals delivered to 64-bit programs breaks dosemu References: <55CA90B4.2010205@list.ru> <55D2D0DE.3080707@list.ru> <55D44DF2.30802@list.ru> In-Reply-To: Content-Type: text/plain; charset=utf-8 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: 3787 Lines: 77 19.08.2015 18:46, Andy Lutomirski пишет: > On Wed, Aug 19, 2015 at 2:35 AM, Stas Sergeev wrote: >>> Incidentally, I tried implementing the sigaction flag approach. I >>> think it's no good. When we return from a signal, there's no concept >>> of sigaction -- it's just sigreturn. Sigreturn can't look up the >>> sigaction flags -- what if the signal handler calls sigaction itself. >> How about the SA_hyz flag that does the following: >> - Saves SS into sigcontext >> - Forces SS to USER_DS on signal delivery >> - Sets the uc_flags flag for sigreturn() to take care of the rest. >> You'll have both the control on every bit of action, and a simple >> detection logic: if SA_hyz didn't set the uc flag - it didn't work. >> You can even employ your lar heuristic here for the case when the >> aforementioned SA_hyz is not set. But please, please not when it is >> set! In fact, I wonder if you had in mind exactly that: using the >> lar heuristic only if the SA_hyz is not set. If so - I misunderstood. >> Just please don't add it when it is set. > > Hmm, interesting. Maybe that would work for everything. How's this > to make it concrete? > > Add a sigaction flag SA_RESTORE_SS. > > On signal delivery, always save SS into sigcontext->ss. if > SA_RESTORE_SS is set, then unconditionally switch HW SS to __USER_DS > and set UC_RESTORE_SS. If SA_RESTORE_SS is clear, then leave HW SS > alone (i.e. preserve the old behavior). Either that, or employ the lar heuristic for the "not set" case (I think its not needed). > On signal return, if UC_RESTORE_SS is set, then restore > sigcontext->ss. If not, then set SS to __USER_DS (as old kernels > did). > > This should change nothing at all (except the initial value of > sigcontext->ss / __pad0) on old kernels. Agreed. >>> So we either need a per-task flag, a per-sighand flag, or a sigcontext >>> flag indicating what we should do. >>> >>> (Yes, I suspect we really might want some way to get FS, GS, and their >>> bases saved and restored, but I still think we should do that >>> separately.) >> In fact, I have already convinced myself that SA_hyz can take >> care of both cases. :) Maybe you'll just need to extend the struct sigaction >> to pass the TLS address, but this doesn't look absolutely impossible... > > I think that should be a separate SA_ flag down the road, Of course separate. I only wanted to get a "somewhat similar" solution, so if the TLS case can also be covered by the (different) SA_ flag (plus perhaps a struct sigaction extension), then its just excellent. What I was afraid of is to get an SS-specific fix, like your initial uc_flags+lar_heuristic solution. Such fix can't be extended to the TLS case, reducing the chances for the TLS case to be ever re-visited. > Also, it occurs to me that FS and GS could become more complicated. > There are some proposals to allow tasks to opt in to having a per-cpu > GS. If that happens, then figuring out how it would interact with > signals could be complicated. Is this a problem? At least on 86_64, according to this: http://wiki.osdev.org/Thread_Local_Storage#x86-64 we only need FS. In any case, since what you say about GS is optional and should be explicitly requested by the task, it can just disable the use of the new SA_TLS flag, making the sigaction() to return error for example. I think the amount of the supported combinations should be limited by the practical needs, and I don't think someone will need per-cpu GS with sighandler re-setting it to something non-per-cpu. -- 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/