From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 57336 invoked by alias); 17 Aug 2016 08:27:40 -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 57322 invoked by uid 89); 17 Aug 2016 08:27:39 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 spammy=his, services X-HELO: mail-wm0-f42.google.com Received: from mail-wm0-f42.google.com (HELO mail-wm0-f42.google.com) (74.125.82.42) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 17 Aug 2016 08:27:38 +0000 Received: by mail-wm0-f42.google.com with SMTP id f65so183662674wmi.0 for ; Wed, 17 Aug 2016 01:27:38 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=pHue8LiWArPmvhblw9xBY4qk5rO40Xmg37UIu+BehVI=; b=TSMjb0xQdyZdcaTk76vZJImZDc3pZ5Rh5hBhwX497oxCd52ErA7hmPZLYDyR7RjX7r qyULaRYbuKNJEigtuKwb5R7yHLBNz5wugY5Ej9P1kU70HKwWmh29XTrLF3g5sUaQr0Eu mgu/DohIvHqvT8xrOMDoyXKeLE+BLujjsIRTJDXj8JuDh87uh4UEgN9eUXeV3aeiOZXa WickBY7V3eI8ODeWlGVCxtl7ABaIzl3mh/IOJG+BXImUEKiyyOKDrkdkkHRLdBtKF7Vg d0kg3ryX8Ek7XzxnZ8xvLl9mfLUezCd63NHAYKYDVWINtKwfcDXFFel2z0s9YD7bDcnv K5ug== X-Gm-Message-State: AEkoouu6hu/tql6vADAdKDL4yI6vjxr3iFp+L/EwXsB/+tycphQ/pDOQZ9nixm1/C56sY+WqFttpiPh/x5CjtA== X-Received: by 10.194.107.33 with SMTP id gz1mr46975987wjb.178.1471422456442; Wed, 17 Aug 2016 01:27:36 -0700 (PDT) MIME-Version: 1.0 Received: by 10.28.137.202 with HTTP; Wed, 17 Aug 2016 01:27:35 -0700 (PDT) In-Reply-To: <57B35338.70405@gmail.com> References: <57A32741.7010003@redhat.com> <57A3F57F.3050509@gmail.com> <57A4A5E8.90205@redhat.com> <57A9D7E5.6090208@redhat.com> <283F73AD-B7CD-4389-908C-BBF479DF9101@gmail.com> <3f8d451d-557d-fb96-7747-dea1c6540cd4@redhat.com> <20160816164424.GZ14857@tucnak.redhat.com> <57abcf31-48aa-6b4c-43bc-357164a11395@redhat.com> <57B35338.70405@gmail.com> From: Richard Biener Date: Wed, 17 Aug 2016 08:27:00 -0000 Message-ID: Subject: Re: protected alloca class for malloc fallback To: Martin Sebor Cc: Jeff Law , Jakub Jelinek , Aldy Hernandez , gcc-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01246.txt.bz2 On Tue, Aug 16, 2016 at 7:54 PM, Martin Sebor wrote: > On 08/16/2016 10:47 AM, Jeff Law wrote: >> >> On 08/16/2016 10:44 AM, Jakub Jelinek wrote: >>> >>> On Tue, Aug 16, 2016 at 10:27:58AM -0600, Jeff Law wrote: >>>> >>>> I think you're being rather short-sighed here. GCC is being used in >>>> ways we >>>> can't necessarily predict -- which might include compile servers, >>>> JITs, web >>>> services, etc. >>> >>> >>> For compile server/web services one needs to add the protection >>> outside of >>> gcc (sandboxing, containers, SELinux, limiting CPU and/or memory, etc.), >>> because even with very short testcases e.g. in C/C++ one can eat >>> arbitrary >>> amounts of stack even without any uses of alloca in the compiler, simply >>> through deep recursion in the parsers etc. >> >> Agreed. However, that doesn't mean we should not be locking down things >> like alloca and other attack vectors. > > > I think I made this suggestion when Aldy posted his first patch > but it didn't get much traction so let me try again. Since the > concern is alloca calls with excessively large arguments, would > transforming those (determined both at compile time and at run > time) into pairs of malloc/free calls be an acceptable compromise? > > It would seem like a natural complement to the transformation > in the opposite direction, brought up back then, of turning calls > to malloc with small (compile-time) arguments into alloca. > > I would expect the malloc optimization to more than outweigh > the performance cost of the alloca to malloc transformation. > Perhaps even to the point to obviate the need for any explicit > alloca calls at all. With the optimization in place, it seems > that it should even be possible to transparently transform at > least the most basic uses of some C++ containers written in > terms of operator new and delete to use alloca instead when > their sizes were known and under the alloca to malloc threshold. Please instead work on sth like -fstack-protector for alloca -- it should be straight-forward to add a runtime test on the stack adjustment being performed against some magic bound (yeah, needs more than only GCC support here). Richard. > Martin