From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751039AbbIBFNP (ORCPT ); Wed, 2 Sep 2015 01:13:15 -0400 Received: from mail-oi0-f42.google.com ([209.85.218.42]:34788 "EHLO mail-oi0-f42.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750743AbbIBFNN convert rfc822-to-8bit (ORCPT ); Wed, 2 Sep 2015 01:13:13 -0400 MIME-Version: 1.0 In-Reply-To: <55D4AF1D.2070100@list.ru> References: <55CA90B4.2010205@list.ru> <55D2D0DE.3080707@list.ru> <55D44DF2.30802@list.ru> <55D4AF1D.2070100@list.ru> From: Andy Lutomirski Date: Tue, 1 Sep 2015 22:12:53 -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: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel 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 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. 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. This is a big problematic for my sigreturn_64 test, but I can deal with that. We could optionally have another UC_RESTORE_EXACT_SS flag that you can set that means "no, really, restore the saved SS". --Andy