Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1753802AbcCGVch (ORCPT ); Mon, 7 Mar 2016 16:32:37 -0500 Received: from mail-ob0-f172.google.com ([209.85.214.172]:35010 "EHLO mail-ob0-f172.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1753228AbcCGVca convert rfc822-to-8bit (ORCPT ); Mon, 7 Mar 2016 16:32:30 -0500 MIME-Version: 1.0 In-Reply-To: <56DDF0B7.1070600@list.ru> References: <568D36A1.1030706@list.ru> <568FBE50.7040504@list.ru> <569065A6.7040005@list.ru> <56DDDE51.8030006@list.ru> <56DDF0B7.1070600@list.ru> From: Andy Lutomirski Date: Mon, 7 Mar 2016 13:32:10 -0800 Message-ID: Subject: Re: sigaltstack breaks swapcontext() To: Stas Sergeev , Linus Torvalds , X86 ML Cc: Linux kernel Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8BIT Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org Content-Length: 3346 Lines: 95 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. > >> 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. > >> 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. 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. But if they're sane and protect just critical pieces of code being tested with AC, we could be polite and clear AC on signal handler entry. --Andy -- Andy Lutomirski AMA Capital Management, LLC