From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1751011AbcEICFR (ORCPT ); Sun, 8 May 2016 22:05:17 -0400 Received: from smtp53.i.mail.ru ([94.100.177.113]:58007 "EHLO smtp53.i.mail.ru" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750894AbcEICFO (ORCPT ); Sun, 8 May 2016 22:05:14 -0400 Subject: Re: [PATCH 1/4] signals/sigaltstack: If SS_AUTODISARM, bypass on_sig_stack To: Andy Lutomirski References: <0081b876-033b-4fb7-3daf-d38b2df1fda6@list.ru> Cc: Thomas Gleixner , Shuah Khan , Pavel Emelyanov , Andrew Morton , Jason Low , "Eric W. Biederman" , Josh Triplett , Aleksa Sarai , Paul Moore , X86 ML , Sasha Levin , Denys Vlasenko , Al Viro , "Amanieu d'Antras" , Borislav Petkov , Konstantin Khlebnikov , Heinrich Schuchardt , Tejun Heo , Brian Gerst , Linux API , Linus Torvalds , Palmer Dabbelt , Frederic Weisbecker , Andrea Arcangeli , Vladimir Davydov , "linux-kernel@vger.kernel.org" , Oleg Nesterov , Richard Weinberger , "H. Peter Anvin" , Peter Zijlstra From: Stas Sergeev Message-ID: <97f8e27a-019c-a5d4-2d2c-c2a9627cf23d@list.ru> Date: Mon, 9 May 2016 05:04:45 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.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.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.