Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753764AbcCGVpP (ORCPT ); Mon, 7 Mar 2016 16:45:15 -0500 Received: from smtp29.i.mail.ru ([94.100.177.89]:50265 "EHLO smtp29.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1752891AbcCGVpI (ORCPT ); Mon, 7 Mar 2016 16:45:08 -0500 Subject: Re: sigaltstack breaks swapcontext() To: Andy Lutomirski , Linus Torvalds , X86 ML References: <568D36A1.1030706@list.ru> <568FBE50.7040504@list.ru> <569065A6.7040005@list.ru> <56DDDE51.8030006@list.ru> <56DDF0B7.1070600@list.ru> Cc: Linux kernel From: Stas Sergeev Message-ID: <56DDF65C.60102@list.ru> Date: Tue, 8 Mar 2016 00:45:00 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.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 Content-Length: 3915 Lines: 82 08.03.2016 00:32, Andy Lutomirski пишет: > On Mon, Mar 7, 2016 at 1:20 PM, Stas Sergeev wrote: >> 08.03.2016 00:10, Andy Lutomirski пишет: >>> On Mon, Mar 7, 2016 at 12:02 PM, Stas Sergeev wrote: >>>> 09.01.2016 04:48, Andy Lutomirski пишет: >>>>> On Fri, Jan 8, 2016 at 5:43 PM, Stas Sergeev wrote: >>>>>> 09.01.2016 02:24, Andy Lutomirski пишет: >>>>>>> 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. >>>>>> Will you take care of this one? >>>>>> Looks quite dangerous for dosemu! And absolutely >>>>>> undebuggable: you never know when you hit it. >>>>> I'll try to remember to tack it on to the sigcontext series. >>>> How is this one going? >> So what do you think about checking SS when >> evaluating the on_sig_stack condition? Will you >> fix this, or should I try? > It fits in with your series, and you're welcome to do it. You can > also poke me and get me to do it. > >>>> There seem to be one more bug in sigcontext handling. >>>> dosemu have this code: >>>> --- >>>> /* >>>> * FIRST thing to do in signal handlers - to avoid being trapped into >>>> int0x11 >>>> * forever, we must restore the eflags. >>>> */ >>>> loadflags(eflags_fs_gs.eflags); >>>> --- >>>> >>>> I quickly checked the kernel code, and it seems the >>>> flags are indeed forgotten, even on ia32! I think the >>>> most dangerous flags are AC and NT. But most of >>>> others are important too. IMHO the safe defaults >>>> should be forced when entering the sighandler. >>>> Would you mind taking a look at this problem too? >>> Clearing NT seems sane. >>> >>> Clearing AC seems like an ABI break, so I'd be a bit nervous about >>> clearing AC unconditionally. >> What exactly do you mean? Is this a documented part of ABI? >> Where can I find out how the flags are supposed to be set on >> entering a sighandler, any docs on that? >> I thought they should just be forced to some default value, the >> same as the segregs are handled. > ABI is that which existing programs rely on, which may or may not be > related to any docs. If there are AC users and they want their signal > handlers to be protected by AC, then this change would break them. But aren't such users (I am sure there are none who use AC in a sighandler) supposed to set the AC flag explicitly in a sighandler? I just thought this is a bug, not an ABI feature at all. So no one should rely on that IMHO. >>> We could add yet another SS flag (sigh), >> But this is not a sigreturn() problem and not sigaltstack() problem, >> so what exactly flag do you mean? > I meant SA_ flag, not SS_. Whoops. But you said "yet another", and we haven't yet added any SA_ flag here. :) >>> or we could make the change. As a more conservative option, we could >>> make it so that AC is cleared on entry to an alignment check signal. >> Hmm. But if we deliver such signal, the userspace will still >> crash, so what's the use? > Userspace could handle the SIGBUS and clear AC from regs->flags if > they were so inclined. Oh, no, I'd better leave popf in the beginning of a sighandler, as it is now done in dosemu. :) > Anyway, maybe Linus or the x86 maintainers have some idea of how AC is > used. If there are people who use it for a whole program and if libc > can survive the experience, then they might expect even signal > handlers to run with AC set. I wonder how do they get such an expectation. It is likely a bug, unexpected behaviour. I wonder if someone could expect this, and I really doubt someone needs AC in a sighandler. So I agree, lets see what other people think, and if there are no couter arguments, lets just force eflags to the default.