From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 125120 invoked by alias); 23 Aug 2017 16:39:23 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 125092 invoked by uid 89); 23 Aug 2017 16:39:23 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy= X-HELO: mail-wm0-f50.google.com Received: from mail-wm0-f50.google.com (HELO mail-wm0-f50.google.com) (74.125.82.50) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 23 Aug 2017 16:39:21 +0000 Received: by mail-wm0-f50.google.com with SMTP id x128so2774763wmg.1 for ; Wed, 23 Aug 2017 09:39:21 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:user-agent:in-reply-to:references :mime-version:content-transfer-encoding:subject:to:cc:from :message-id; bh=SMmLGc6Yj5gEMNzkLRchp2I2CA/vQdw9ikC6ZKhaOrc=; b=jJJr7tYSjs1sqgAzePuttIxkva+KyG6jOAjDpKjjZm/T2f4ka/bEk5HVqGIiDWJlsF EbqbuBi8j0NuargFJPvahPHCLXIuFfOrBjfT5iEF58ODtlqebwaABhZDcE+7mTtAI3dX qa5CzkwkKuNjciGycN29GRgV1JvQ+OwB4E/op3hlAArwhKcQDH4OM6to4EiiDGS7aF9+ VnWKW4RA3r+yoY5PPlaBPeLthJAvvqV3qpzh3LFLdXXcPntnF79+YR/+5VcFtRVYhxO1 +R/tmmX2e43epLZ4jWMOYC18DYKgHlJrCR2y6Z8JRcnYOFtiOkdTVUGs0qP9RZI6OQwJ mFoA== X-Gm-Message-State: AHYfb5hLg+fIGqEyfQi3bonkuLPjn8ZhqSd2NzoEPt3LScCFo34gRf21 QZ8CB6/iPZs/iA== X-Received: by 10.80.138.218 with SMTP id k26mr3604522edk.239.1503506359655; Wed, 23 Aug 2017 09:39:19 -0700 (PDT) Received: from android-f83b394395796e13.fritz.box (p5494E583.dip0.t-ipconnect.de. [84.148.229.131]) by smtp.gmail.com with ESMTPSA id c56sm381877eda.77.2017.08.23.09.39.17 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 23 Aug 2017 09:39:18 -0700 (PDT) Date: Wed, 23 Aug 2017 17:31:00 -0000 User-Agent: K-9 Mail for Android In-Reply-To: <5bfeb932-02c2-c12d-05cf-8dc451963de7@redhat.com> References: <4194c6f8-4efb-3eaa-f165-367b252605c0@redhat.com> <5bfeb932-02c2-c12d-05cf-8dc451963de7@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Subject: Re: [PATCH][RFA/RFC] Stack clash mitigation patch 01/08 - V3 To: Jeff Law CC: gcc-patches From: Richard Biener Message-ID: <72B6AD1A-0C1A-47C6-9C98-FED8CFAC0A75@gmail.com> X-IsSubscribed: yes X-SW-Source: 2017-08/txt/msg01386.txt.bz2 On August 23, 2017 6:36:32 PM GMT+02:00, Jeff Law wrote: >On 08/23/2017 03:07 AM, Richard Biener wrote: > >>>> Both -fstack-clash-protection and -fstack-check cannot be turned >>>> off per function. This means they would need merging in >lto-wrapper. >>>> The alternative is to mark them with 'Optimization' and allow >per-function >>>> specification (like we do for -fstack-protector). >>> Do you have a strong preference here? I'd tend to go with tweaking >>> lto-wrapper as we really don't want to have this stuff varying >per-function. >>=20 >> Any reason? I see no technical one at least, it might break IPA >assumptions >> you make when instrumenting? I guess you just don't want to think >about >> the implications when mixing them (or mixing -fstack-clash-protection >> with -fno-stack-clash-protection)? >On some targets (s390 for example), a stack guard jump can be >accomplished by a combination of caller and callee stack adjustments -- >even though neither the caller nor the callee have a large enough >adjustment individually to jump the guard. > >So a mis-informed developer could audit their code, declare various >functions as safe & turn off protections on a per-function basis based >on that analysis. But that would be mis-guided as it opens them up to >a >potential attack where the combination of caller and callee stack >adjustments are used to jump the guard. > > > > > >>=20 >>> Presumably in lto-wrapper we just have to detect that both were >enabled >>> and do something sensible. We drop -fstack-check in toplev.c when >both >>> are specified, we could just as easily call that situation a fatal >error >>> in both toplev.c and lto-wrapper.c >>=20 >> So what happens if you LTO link Ada (-fstack-check) with C >> (-fstack-clash-protection)? >When in the Ada code you'll be mostly protected from stack clashes and >you can detect stack overflows and catch the signal properly. When in >C >code, you'd be fully protected from stack clash, but not necessarily >able to take a signal. > >At the boundaries where you call from Ada to C, you're potentially >vulnerable to stack clash on architectures like aarch64/s390. When >calling from C into Ada, you're not guaranteed to be able to handle a >signal when you overflow the stack. > >> The user is already allowed to (without LTO) specify things on a CU >granularity. >True. And you end up with a mixture of protections depending on what >code is executing or what boundary you're crossing. So the natural thing for LTO ist to make it function granular. That way you= don't need any magic in LTO-wrapper.=20 Richard.=20 > >Jeff