Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.kernel > #1354987

Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with other arches

Path csiph.com!weretis.net!feeder6.news.weretis.net!news.glorb.com!bofh.it!news.nic.it!robomod
From Ingo Molnar <mingo@kernel.org>
Newsgroups linux.kernel
Subject Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with other arches
Date Thu, 10 Mar 2016 11:30:02 +0100
Message-ID <rb60W-5G6-5@gated-at.bofh.it> (permalink)
References <r4Liy-4Uy-9@gated-at.bofh.it> <r5Zt8-120-7@gated-at.bofh.it> <r633H-3FK-13@gated-at.bofh.it> <rasGf-3hq-39@gated-at.bofh.it> <raWkW-7mX-9@gated-at.bofh.it>
X-Original-To Andy Lutomirski <luto@amacapital.net>
Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=VcN38vDwDdNZ/zxnXMltq24PlcuRJ+PDSv0ro8b1UBU=; b=ZSSFferzb86SuQAaJDGgXY/1VPnY94D5Z3/3iDAl0aCxcnztoShJnUkKByp/IhLFOp frWqOpc3Q2+WJgAdn4bjitK+DYmhnikvc49mFagkycOI6jNCexUAkcybVF3Oed2oBSGL C0cwkjJrwmhM9M9xY1Wo6LurCB+atsfdvCGGKAdiY1qSG5tP4kxXsv1x2rsVmD8zQbFC PxJ/wneeXTNyYrqj8c6FJIUpWhbcLR43d7QULXvx8WrrcBDr6wzm94bl8iYtDTelkmfQ m5jS0CK0uAva8dCemUeEYaUQJrxnDzwlbzxHHJidS3ZAzwnLzOFhnqWJeAwegjpvexfM A9bA==
X-Google-Dkim-Signature v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:sender:date:from:to:cc:subject:message-id :references:mime-version:content-disposition :content-transfer-encoding:in-reply-to:user-agent; bh=VcN38vDwDdNZ/zxnXMltq24PlcuRJ+PDSv0ro8b1UBU=; b=fytUMpLepmQPekk0KxSsODq//UQoycXw859uSfz5OLV3gTXwqzVXSUK4XQcgbhJNjz X1wOEc3J33gKo1A9hs3ZU3AffQb6BUZ/hZSOjDzP8UD8fj7RTX0iGCkTAZHT32HT4VRL 2oWRdG+tZKTU/Qf6jRi5oBhmYqT13fKRrQHQJjW+tf3cg4KROVs5nhmYGTkKyLvNcTNg yypOqys2dIDPt/nvRNS/EilU42XvWoSoElQ6V0ximLDDNma1lzOZI81X3i3ct1ZfGdGQ zDbc4t5Xpfkq0lUIpangjku4OBchkRUqlrKxzuSi51XP/WCPDdbT2eadrLPrJJqtKmKk fpUQ==
X-Gm-Message-State AD7BkJLDnDlg8BBcqnUpiguoMdTOIP6YwJ85IvQxODzi7DUb5JgHLOOJcaJFaZtQZCr3Cw==
X-Received by 10.28.147.72 with SMTP id v69mr2762921wmd.79.1457605581331; Thu, 10 Mar 2016 02:26:21 -0800 (PST)
MIME-Version 1.0
Content-Type text/plain; charset=utf-8
Content-Disposition inline
Content-Transfer-Encoding 8bit
User-Agent Mutt/1.5.23 (2014-03-12)
Sender robomod@news.nic.it
List-ID <linux-kernel.vger.kernel.org>
X-Mailing-List linux-kernel@vger.kernel.org
Approved robomod@news.nic.it
Lines 94
Organization linux.* mail to news gateway
X-Original-Cc Stas Sergeev <stsp@list.ru>, "linux-kernel@vger.kernel.org" <linux-kernel@vger.kernel.org>, Thomas Gleixner <tglx@linutronix.de>, Ingo Molnar <mingo@redhat.com>, "H. Peter Anvin" <hpa@zytor.com>, X86 ML <x86@kernel.org>, Borislav Petkov <bp@suse.de>, Brian Gerst <brgerst@gmail.com>, Oleg Nesterov <oleg@redhat.com>, Richard Weinberger <richard@nod.at>, Stas Sergeev <stsp@users.sourceforge.net>
X-Original-Date Thu, 10 Mar 2016 11:26:18 +0100
X-Original-Message-ID <20160310102618.GB21593@gmail.com>
X-Original-References <1456095685-23857-1-git-send-email-stsp@list.ru> <20160225082524.GA12294@gmail.com> <56CEF02C.7050906@list.ru> <20160308162046.GA30211@gmail.com> <CALCETrWSr86vBo=Va-t687A1zEszZJZjG350+-2GCOhM-kLuSA@mail.gmail.com>
X-Original-Sender linux-kernel-owner@vger.kernel.org
Xref csiph.com linux.kernel:1354987

Show key headers only | View raw


* Andy Lutomirski <luto@amacapital.net> wrote:

> On Tue, Mar 8, 2016 at 8:20 AM, Ingo Molnar <mingo@kernel.org> wrote:
> >
> > * Stas Sergeev <stsp@list.ru> wrote:
> >
> >> 25.02.2016 11:25, Ingo Molnar пишет:
> >> >
> >> > * Stas Sergeev <stsp@list.ru> wrote:
> >> >
> >> >> Currently x86's get_sigframe() checks for "current->sas_ss_size"
> >> >> to determine whether there is a need to switch to sigaltstack.
> >> >> The common practice used by all other arches is to check for
> >> >> sas_ss_flags(sp) == 0
> >> >>
> >> >> This patch makes the code consistent with other arches.
> >> >> The slight complexity of the patch is added by the optimization on
> >> >> !sigstack check that was requested by Andy Lutomirski: sas_ss_flags(sp)==0
> >> >> already implies that we are not on a sigstack, so the code is shuffled
> >> >> to avoid the duplicate checking.
> >> >
> >> > So this changelog is missing an analysis about what effect this change will have
> >> > on applications. Can any type of user-space code see a change in behavior? If yes,
> >> > what will happen and is that effect desirable?
> >> This is a clean-up, and as such, there is no visible effect.
> >> If there is - it is a bug.
> >> The purpose of this patch is only to unify the x86 code with
> >> what all the other arches do. It was initially the part of the
> >> rejected series, but now it is just a clean-up.
> >
> > Ok, so AFAICS the relevant change is:
> >
> > -               if (current->sas_ss_size)
> > -                       sp = current->sas_ss_sp + current->sas_ss_size;
> > +               if (sas_ss_flags(sp) == 0)
> > +                       sp = current->sas_ss_sp + current->sas_ss_size;
> >
> > and since sas_ss_flags() is defined as:
> >
> > static inline int sas_ss_flags(unsigned long sp)
> > {
> >         if (!current->sas_ss_size)
> >                 return SS_DISABLE;
> >
> >         return on_sig_stack(sp) ? SS_ONSTACK : 0;
> > }
> >
> > sas_ss_flags() returns 0 iff current->sas_ss_size && !on_sig_stack().
> >
> > But we already have on_sig_stack(sp) calculated. Why not write that as:
> >
> > +               if (current->sas_ss_size && !onsigstack)
> > +                       sp = current->sas_ss_sp + current->sas_ss_size;
> >
> > and since we check '!onsigstack' in both branches, we might as well factor it out
> > into a single condition ... and arrive to the exact code that we began with.
> 
> ISTM it's silly for us to be unconditionally computing onsigstack.
> We're doing it because we need it later for this:
> 
>         /*
>          * If we are on the alternate signal stack and would overflow it, don't.
>          * Return an always-bogus address instead so we will die with SIGSEGV.
>          */
>         if (onsigstack && !likely(on_sig_stack(sp)))
>                 return (void __user *)-1L;
> 
> This seems basically useless to me.  Sure, it's nice to send SIGSEGV
> if we overflow due to signal delivery.  But we're almost as likely to
> overflow in the signal handler as we are to overflow during delivery,
> and we don't even try to catch that.

Ok, I was just put off by the code size difference - but no strong opinion from 
me, I'd certainly be fine with (as a first step) harmonizing the implementation 
with other architectures. I withdraw my objection.

> Anyway, I think we should make two changes to the sig_on_stack thing:
> 
> 1. If SS_AUTODISARM, then we're not on the stack, regardless of what sp says.
> 
> 2. If !user_64bit_mode(regs) && (regs->ss & 0x4), then we're not on
> the signal stack.  This will happen if we're running on an LDT stack
> and we coincidentally have the ESP part of SS:ESP matching the signal
> stack.
> 
> In general, the existing design is crap and it should always have
> worked the way that Stas is proposing with SS_AUTODISARM.

Ok, no objections here either.

Thanks,

	Ingo

Back to linux.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with  other arches Ingo Molnar <mingo@kernel.org> - 2016-03-08 17:30 +0100
  Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with  other arches Stas Sergeev <stsp@list.ru> - 2016-03-08 18:00 +0100
  Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with  other arches Andy Lutomirski <luto@amacapital.net> - 2016-03-10 01:10 +0100
    Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with  other arches Ingo Molnar <mingo@kernel.org> - 2016-03-10 11:30 +0100
    Re: [PATCH] [Cleanup] x86: signal: unify the sigaltstack check with  other arches Stas Sergeev <stsp@list.ru> - 2016-03-10 13:10 +0100

csiph-web