Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753535AbcCGVVR (ORCPT ); Mon, 7 Mar 2016 16:21:17 -0500 Received: from smtp35.i.mail.ru ([94.100.177.95]:34591 "EHLO smtp35.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753339AbcCGVVD (ORCPT ); Mon, 7 Mar 2016 16:21:03 -0500 Subject: Re: sigaltstack breaks swapcontext() To: Andy Lutomirski References: <568D36A1.1030706@list.ru> <568FBE50.7040504@list.ru> <569065A6.7040005@list.ru> <56DDDE51.8030006@list.ru> Cc: Linux kernel From: Stas Sergeev Message-ID: <56DDF0B7.1070600@list.ru> Date: Tue, 8 Mar 2016 00:20:55 +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: 2289 Lines: 53 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? >> 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. > 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? > 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?