From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1754223AbbIBWZh (ORCPT ); Wed, 2 Sep 2015 18:25:37 -0400 Received: from mail-oi0-f50.google.com ([209.85.218.50]:35098 "EHLO mail-oi0-f50.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752689AbbIBWZf convert rfc822-to-8bit (ORCPT ); Wed, 2 Sep 2015 18:25:35 -0400 MIME-Version: 1.0 In-Reply-To: <55E7774F.6060907@list.ru> 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> From: Andy Lutomirski Date: Wed, 2 Sep 2015 15:25:15 -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, Sep 2, 2015 at 3:25 PM, Stas Sergeev wrote: > 03.09.2015 00:39, Andy Lutomirski пишет: > >> On Wed, Sep 2, 2015 at 2:01 PM, Stas Sergeev wrote: >>> >>> 02.09.2015 22:06, Andy Lutomirski пишет: >>> >>>> On Wed, Sep 2, 2015 at 11:23 AM, Stas Sergeev wrote: >>>>> >>>>> 02.09.2015 21:17, Andy Lutomirski пишет: >>>>>> >>>>>> On Wed, Sep 2, 2015 at 10:46 AM, Stas Sergeev wrote: >>>>>>> >>>>>>> 02.09.2015 17:21, Andy Lutomirski пишет: >>>>>>>>>> >>>>>>>>>> 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 >>>>>>>> >>>>>>>> What's the issue here? I don't understand. >>>>>>>> >>>>>>>> On musl, (sig)longjmp just restores rsp, rbx, rbp, and r12-r15, so >>>>>>>> it >>>>>>>> won't be affected. AFAIK all implementations of siglongjmp are >>>>>>>> likely >>>>>>>> to call sigprocmask or similar, and that will clobber SS. I'm not >>>>>>>> aware of an implementation of siglongjmp that uses sigreturn. >>>>>>> >>>>>>> I am not saying siglongjmp() will be affected. >>>>>>> Quite the opposite: it won't, which is bad. :) >>>>>>> If you have always correct SS, you can use siglongjmp(). If you have >>>>>>> broken SS at times, siglongjmp() will be an asking for troubles, as >>>>>>> it exactly does not restore SS. >>>>>>> dosemu could do a good use of siglongjmp() to get back to 64bit code >>>>>>> from its sighandler. >>>>>> >>>>>> This seems like it would be relying unpleasantly heavily on libc >>>>>> internals. >>>>> >>>>> Could you please clarify? >>>>> If kernel always passes the right SS to the sighandler, then what's >>>>> the problem? >>>> >>>> What's the exact siglongjmp usage you have in mind? Signal context >>>> isn't normally involved AFAIK. >>> >>> dosemu needs 2 return pathes: >>> 1. to DOS code >>> 2. to 64bit code (dosemu is not all in a sighandler, right?) >>> >>> How it is currently achieved: >>> dosemu1: >>> 1. sigreturn() + iret (to DOS) >>> 2. modify sigcontext -> sigreturn() (to 64bit asm helper) >>> >>> dosemu2: >>> 1. sigreturn() + iret (to DOS) >>> 2. modify sigcontext -> sigreturn() -> longjmp() (to 64bit C-coded) >> >> So you're modifying sigcontext such that it returns to a C function >> that calls longjmp? > > Yes. > >>> 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. >> 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, although that's still a longer-term thing. --Andy -- Andy Lutomirski AMA Capital Management, LLC