From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755712AbbIBSYA (ORCPT ); Wed, 2 Sep 2015 14:24:00 -0400 Received: from smtp33.i.mail.ru ([94.100.177.93]:50673 "EHLO smtp33.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1751615AbbIBSX7 (ORCPT ); Wed, 2 Sep 2015 14:23:59 -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> Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel From: Stas Sergeev Message-ID: <55E73EB5.5040204@list.ru> Date: Wed, 2 Sep 2015 21:23:49 +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 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 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? >>>> - Async signals can silently "validate" SS behind your back >>> >>> True, and that's unfortunate. But async signals without SA_SAVE_SS >>> set with the other approach have exactly the same problem. >> Yes, and as such, they should be blocked. >> You could improve on that and on siglongjmp(). >> And on TLS in the future. > > *I* can't do anything to siglongjmp because that's almost entirely > outside the kernel. :-/ Except for passing the SS=__USER_DS to the sighandler, for which we discussed the new SA_hyz? >>>> Is the new SA flag such a big deal here to even bother? >>> >>> Not really, but given that the new behavior seems clearly better >>> behaved than the old, it would be nice to be able to have the good >>> behavior, or at least most of it, be the default. >> Surely, but how about then having the heuristics you suggest, >> only if the new SA_hyz is not set? And when it is set, have a >> properly defined and predictable behaviour. Then it seems like >> we'll get all the possible wishes covered. > > That could work. The result is quite similar to explicitly setting > UC_STRICT_RESTORE_SS. I am much more bothered with delivering the right SS than with restoring it on sigreturn().