From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1752308AbbIBW46 (ORCPT ); Wed, 2 Sep 2015 18:56:58 -0400 Received: from smtp29.i.mail.ru ([94.100.177.89]:44065 "EHLO smtp29.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751319AbbIBW45 (ORCPT ); Wed, 2 Sep 2015 18:56:57 -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> <55E6BEAC.8080302@list.ru> <55E735FE.1030901@list.ru> <55E73EB5.5040204@list.ru> <55E7638F.1060002@list.ru> <55E7774F.6060907@list.ru> Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel From: Stas Sergeev Message-ID: <55E77FCC.2080500@list.ru> Date: Thu, 3 Sep 2015 02:01: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 03.09.2015 01:25, Andy Lutomirski пишет: > On Wed, Sep 2, 2015 at 3:25 PM, Stas Sergeev wrote: > >>>> How dosemu2 is supposed to do this: >>>> 1. sigreturn() (to DOS) >>>> 2. siglongjmp() (to 64bit C-coded) >>> This should work fine on any kernel, right? >> 1 - not. >> 2 - maybe. >> If, as you say, siglongjmp() restores SS, I need to try it out. >> (there is also a problem that most siglongjmp() implementations >> are incompatible with sigaltstack(), but this is not what you can fix). >> > 1 - definitely needs kernel changes. I was referring to #2. > > 2 - siglongjmp probably varies in its behavior across different libc > implementations. My point is that siglongjmp isn't a kernel-provided > thing. So if siglongjmp() restores SS by the side-effect of doing a sigprocmask() syscall, this admittedly weakens my point. The unreliability then stays only with the async signals interrupting the main one. >>> For backwards compat, we either need the default behavior to be >>> unchanged, or we need the default behavior to be something that works >>> with existing dosemu. For existing dosemu, the only interesting cases >>> (I think) are signal delivery from *valid* 16-bit context, in which >>> case we need to preserve SS so that the signal handler can read it out >>> with mov ..., %ss, and sigreturn to 64-bit mode for the IRET >>> trampoline. For sigreturn, IIUC old dosemu will replace the saved CS >>> with a 64-bit code segment selector and won't touch the saved SS >>> because it doesn't know about the saved SS. Those dosemu versions >>> don't care what SS actually contains after sigreturn, because they're >>> immediately going to change it again using IRET. So we just need to >>> make sure we return without faulting. >>> >>> New dosemu2 would like to sigreturn directly back to 16-bit mode, so >>> it needs the kernel to honor the saved ss value and restore it, >>> possibly changed by dosemu. >>> >>> We obviously can't require old dosemu to set an SA flag to keep >>> working. But, if we can get away with it, I think it's somewhat >>> preferable not to require new DOSEMU to set an SA flag either. >>> >>> This has one major benefit at least: if new dosemu loads some random >>> library that installs some async signal handler (SIGALRM for example), >>> everything will work with regard to CS and SS. >> This case is covered if we do both things together: use >> your heuristic when SA_hyz is not set, and don't use it >> when its set. In this case dosemu2 will be able to request >> the proper SS delivery for its sighandlers, but the 3rd-party >> sighandlers will work too. >> I think we have never discussed the possibility of doing >> both things together, even though I have proposed it many >> times. >> After discussing this full-blown solution, we can think about >> reducing it, either by removing the heuristic or by removing >> SA_hyz, but discussing the full one would be nice too. >> Your opinion is likely that no one will use this SA_hyz in >> presence of the heuristic that "seems to work anyway". >> But in the light of extending it for TLS (with a new flag), >> I wouldn't be so sure. You can also document it as a >> needed flag when user code touches SS, and then it will >> be used. dosemu1 code that doesn't use it, will eventually >> be forgotten. So IMHO whether it will be used, is fully up >> to how will you market it. :) > I'll think about it. I'll think about FS and GS, too, OK, thanks.