From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751440AbcENESo (ORCPT ); Sat, 14 May 2016 00:18:44 -0400 Received: from mail-oi0-f41.google.com ([209.85.218.41]:34076 "EHLO mail-oi0-f41.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750853AbcENESm convert rfc822-to-8bit (ORCPT ); Sat, 14 May 2016 00:18:42 -0400 MIME-Version: 1.0 In-Reply-To: <97f8e27a-019c-a5d4-2d2c-c2a9627cf23d@list.ru> References: <0081b876-033b-4fb7-3daf-d38b2df1fda6@list.ru> <97f8e27a-019c-a5d4-2d2c-c2a9627cf23d@list.ru> From: Andy Lutomirski Date: Fri, 13 May 2016 21:18:21 -0700 Message-ID: Subject: Re: [PATCH 1/4] signals/sigaltstack: If SS_AUTODISARM, bypass on_sig_stack To: Stas Sergeev Cc: Thomas Gleixner , Pavel Emelyanov , Shuah Khan , X86 ML , Andrew Morton , Linux API , Jason Low , "Eric W. Biederman" , Aleksa Sarai , Josh Triplett , "linux-kernel@vger.kernel.org" , Paul Moore , Sasha Levin , Denys Vlasenko , Al Viro , Borislav Petkov , "Amanieu d'Antras" , Konstantin Khlebnikov , Heinrich Schuchardt , Brian Gerst , Tejun Heo , Linus Torvalds , Andrea Arcangeli , Frederic Weisbecker , Palmer Dabbelt , Vladimir Davydov , Oleg Nesterov , Richard Weinberger , "H. Peter Anvin" , Peter Zijlstra 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 On May 8, 2016 7:05 PM, "Stas Sergeev" wrote: > > 09.05.2016 04:32, Andy Lutomirski пишет: > >> On May 7, 2016 7:38 AM, "Stas Sergeev" wrote: >>> >>> 03.05.2016 20:31, Andy Lutomirski пишет: >>> >>>> If a signal stack is set up with SS_AUTODISARM, then the kernel >>>> inherently avoids incorrectly resetting the signal stack if signals >>>> recurse: the signal stack will be reset on the first signal >>>> delivery. This means that we don't need check the stack pointer >>>> when delivering signals if SS_AUTODISARM is set. >>>> >>>> This will make segmented x86 programs more robust: currently there's >>>> a hole that could be triggered if ESP/RSP appears to point to the >>>> signal stack but actually doesn't due to a nonzero SS base. >>>> >>>> Signed-off-by: Stas Sergeev >>>> Cc: Al Viro >>>> Cc: Aleksa Sarai >>>> Cc: Amanieu d'Antras >>>> Cc: Andrea Arcangeli >>>> Cc: Andrew Morton >>>> Cc: Andy Lutomirski >>>> Cc: Borislav Petkov >>>> Cc: Brian Gerst >>>> Cc: Denys Vlasenko >>>> Cc: Eric W. Biederman >>>> Cc: Frederic Weisbecker >>>> Cc: H. Peter Anvin >>>> Cc: Heinrich Schuchardt >>>> Cc: Jason Low >>>> Cc: Josh Triplett >>>> Cc: Konstantin Khlebnikov >>>> Cc: Linus Torvalds >>>> Cc: Oleg Nesterov >>>> Cc: Palmer Dabbelt >>>> Cc: Paul Moore >>>> Cc: Pavel Emelyanov >>>> Cc: Peter Zijlstra >>>> Cc: Richard Weinberger >>>> Cc: Sasha Levin >>>> Cc: Shuah Khan >>>> Cc: Tejun Heo >>>> Cc: Thomas Gleixner >>>> Cc: Vladimir Davydov >>>> Cc: linux-api@vger.kernel.org >>>> Cc: linux-kernel@vger.kernel.org >>>> Signed-off-by: Andy Lutomirski >>>> --- >>>> include/linux/sched.h | 12 ++++++++++++ >>>> 1 file changed, 12 insertions(+) >>>> >>>> diff --git a/include/linux/sched.h b/include/linux/sched.h >>>> index 2950c5cd3005..8f03a93348b9 100644 >>>> --- a/include/linux/sched.h >>>> +++ b/include/linux/sched.h >>>> @@ -2576,6 +2576,18 @@ static inline int kill_cad_pid(int sig, int priv) >>>> */ >>>> static inline int on_sig_stack(unsigned long sp) >>>> { >>>> + /* >>>> + * If the signal stack is AUTODISARM then, by construction, we >>>> + * can't be on the signal stack unless user code deliberately set >>>> + * SS_AUTODISARM when we were already on the it. >>> >>> "on the it" -> "on it". >>> >>> Anyway, I am a bit puzzled with this patch. >>> You say "unless user code deliberately set >>> >>> SS_AUTODISARM when we were already on the it" >>> so what happens in case it actually does? >>> >> Stack corruption. Don't do that. > > Only after your change, I have to admit. :) > > >>> Without your patch: if user sets up the same sas - no stack switch. >>> if user sets up different sas - stack switch on nested signal. >>> >>> With your patch: stack switch in any case, so if user >>> set up same sas - stack corruption by nested signal. >>> >>> Or am I missing the intention? >> >> The intention is to make everything completely explicit. With >> SS_AUTODISARM, the kernel knows directly whether you're on the signal >> stack, and there should be no need to look at sp. If you set >> SS_AUTODISARM and get a signal, the signal stack gets disarmed. If >> you take a nested signal, it's delivered normally. When you return >> all the way out, the signal stack is re-armed. >> >> For DOSEMU, this means that no 16-bit register state can possibly >> cause a signal to be delivered wrong, because the register state when >> a signal is raised won't affect delivery, which seems like a good >> thing to me. > > Yes, but doesn't affect dosemu1 which doesn't use SS_AUTODISARM. > So IMHO the SS check should still be added, even if not for dosemu2. > > >> If this behavior would be problematic for you, can you explain why? > > Only theoretically: if someone sets SS_AUTODISARM inside a > sighandler. Since this doesn't give EPERM, I wouldn't deliberately > make it a broken scenario (esp if it wasn't before the particular change). > Ideally it would give EPERM, but we can't, so doesn't matter much. > I just wanted to warn about the possible regression. I suppose we could return an error if you are on the sigstack when setting SS_AUTODISARM, although I was hoping to avoid yet more special cases. > -- > To unsubscribe from this list: send the line "unsubscribe linux-api" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html