From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19199 invoked by alias); 16 Aug 2016 16:47:34 -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 19188 invoked by uid 89); 16 Aug 2016 16:47:34 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=willingness, tackle, Hx-languages-length:1299, services X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 16 Aug 2016 16:47:33 +0000 Received: from int-mx11.intmail.prod.int.phx2.redhat.com (int-mx11.intmail.prod.int.phx2.redhat.com [10.5.11.24]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 1692B83F3B; Tue, 16 Aug 2016 16:47:32 +0000 (UTC) Received: from localhost.localdomain (ovpn-116-13.phx2.redhat.com [10.3.116.13]) by int-mx11.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7GGlVJe025859; Tue, 16 Aug 2016 12:47:31 -0400 Subject: Re: protected alloca class for malloc fallback To: Jakub Jelinek 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> Cc: Richard Biener , Aldy Hernandez , Martin Sebor , gcc-patches From: Jeff Law Message-ID: <57abcf31-48aa-6b4c-43bc-357164a11395@redhat.com> Date: Tue, 16 Aug 2016 16:47:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: <20160816164424.GZ14857@tucnak.redhat.com> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01205.txt.bz2 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. The attack vector is so big that > trying to do something just about alloca is IMHO pointless, and we really > don't want to fight 20 gcc CVEs every day (1:1 with most bugreports). > Alloca is really useful in the compiler IMO, it is significantly faster than > heap allocation, and that is what matters in many places a lot. You have to start somewhere and we have the tools and willingness of an engineer to tackle part of this problem. Simply giving up because it's not a total solution is absurd. jeff