From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753464AbbIBJNR (ORCPT ); Wed, 2 Sep 2015 05:13:17 -0400 Received: from smtp40.i.mail.ru ([94.100.177.100]:35796 "EHLO smtp40.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752194AbbIBJNP (ORCPT ); Wed, 2 Sep 2015 05:13:15 -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> <55D2D0DE.3080707@list.ru> <55D44DF2.30802@list.ru> <55D4AF1D.2070100@list.ru> Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel From: Stas Sergeev Message-ID: <55E6BEAC.8080302@list.ru> Date: Wed, 2 Sep 2015 12:17:32 +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 02.09.2015 08:12, Andy Lutomirski пишет: > On Wed, Aug 19, 2015 at 9:30 AM, Stas Sergeev wrote: >> 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. >> > Let me throw out one more possibility, just for completeness: > > We don't add any SA_xyz flags. On signal delivery, we use the LAR > heuristic. We always fill in sigcontext->ss, and we set a new > UC_SIGCONTEXT_SS flag to indicate that we support the new behavior. > > On sigreturn, we honor the sigcontext's ss, *unless* CS is 64 bit and > SS is invalid. In the latter case, we replace the saved ss with > __USER_DS. But this is not a new proposal, see here: https://lkml.org/lkml/2015/8/13/436 The very last sentence says exactly the same. I thought this is in the past. :) > This should work for old DOSEMU. It's a bit gross, but it has the > nice benefit that everyone (even things that aren't DOSEMU) gain the > ability to catch signals thrown from bogus SS contexts, which probably > improves debugability. It's also nice to not have the SA flag. Pros: - No new SA flag - May improve debugability in some unknown scenario where people do not want to just use the new flag to get their things improved Cons: - Does not allow to cleanly use siglongjmp(), as then there is a risk to jump to 64bit code with bad SS - Async signals can silently "validate" SS behind your back - No way to extend that solution to later fixing the TLS problem - Many ugly checks in the code, that are not always even obvious (eg you wanted to try verw instead, and there was a gotcha with NP bit) Is the new SA flag such a big deal here to even bother?