From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755859AbbIBRqp (ORCPT ); Wed, 2 Sep 2015 13:46:45 -0400 Received: from smtp36.i.mail.ru ([94.100.177.96]:47618 "EHLO smtp36.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1755613AbbIBRqo (ORCPT ); Wed, 2 Sep 2015 13:46:44 -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> Cc: Linus Torvalds , Raymond Jennings , Cyrill Gorcunov , Pavel Emelyanov , Linux kernel From: Stas Sergeev X-Enigmail-Draft-Status: N1110 Message-ID: <55E735FE.1030901@list.ru> Date: Wed, 2 Sep 2015 20:46:38 +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 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. >> - 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. >> 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.