From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1756056AbcAHXkM (ORCPT ); Fri, 8 Jan 2016 18:40:12 -0500 Received: from smtp53.i.mail.ru ([94.100.177.113]:49589 "EHLO smtp53.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754288AbcAHXkL (ORCPT ); Fri, 8 Jan 2016 18:40:11 -0500 Subject: Re: sigaltstack breaks swapcontext() To: Andy Lutomirski References: <568D36A1.1030706@list.ru> <568FBE50.7040504@list.ru> Cc: Linux kernel From: Stas Sergeev Message-ID: <569048D3.6000309@list.ru> Date: Sat, 9 Jan 2016 02:40:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.4.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 09.01.2016 02:24, Andy Lutomirski пишет: > On Fri, Jan 8, 2016 at 5:49 AM, Stas Sergeev wrote: >> 06.01.2016 21:05, Andy Lutomirski пишет: >>> On Wed, Jan 6, 2016 at 7:45 AM, Stas Sergeev wrote: >>> >>>> Hello. >>>> >>>> swapcontext() can be used with signal handlers, >>>> it swaps the signal masks together with the other >>>> parts of the context. >>>> Unfortunately, linux implements the sigaltstack() >>>> in a way that makes it impossible to use with >>>> swapcontext(). >>>> Per the man page, sigaltstack is allowed to return >>>> EPERM if the process is altering its sigaltstack while >>>> running on sigaltstack. This is likely needed to >>>> consistently return oss->ss_flags, that indicates >>>> whether the process is being on sigaltstack or not. >>>> Unfortunately, linux takes that permission to return >>>> EPERM too literally: it returns EPERM even if you >>>> don't want to change to another sigaltstack, but >>>> only want to disable sigaltstack with SS_DISABLE. >>>> To my reading of a man page, this is not a desired >>>> behaviour. Moreover, you can't use swapcontext() >>>> without disabling sigaltstack first, or the stack will >>>> be re-used and overwritten by a subsequent signal. >>>> >>> The EPERM thing is probably also to preserve the behavior that nested >>> SA_ONSTACK signals are supposed to work. (Of course, the kernel gets >>> this a bit wrong because it forgets to check ss in addition to sp. >>> That would be relatively straightforward to fix.) >> I don't think it needs a fix: in 64bit mode SS doesn't matter, and >> in 32bit mode the SS is properly restored in a sighandler, so no >> one can run sigaltstack() with non-flat SS (unless the DOS code >> itself does this, which it does not). > It's not sigaltstack that I'm thinking about. It's signal delivery. > If you end up in DOS mode with SP coincidentally pointing to the > sigaltstack (but with different SS so it's not really the > sigaltstack), then the signal delivery will malfunction. Ah, sounds like a real bug then! Though if bitness differ (64bit mode and signal comes from 32bit code), there is probably no need to check anything and just switch the stack.