From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13592 invoked by alias); 16 Aug 2016 16:44:32 -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 13582 invoked by uid 89); 16 Aug 2016 16:44:31 -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=fight, limiting, amounts, 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:44:30 +0000 Received: from int-mx14.intmail.prod.int.phx2.redhat.com (int-mx14.intmail.prod.int.phx2.redhat.com [10.5.11.27]) (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 77B58C05091E; Tue, 16 Aug 2016 16:44:29 +0000 (UTC) Received: from tucnak.zalov.cz (ovpn-204-43.brq.redhat.com [10.40.204.43]) by int-mx14.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u7GGiRnL002705 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=NO); Tue, 16 Aug 2016 12:44:29 -0400 Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id u7GGiQDM030856; Tue, 16 Aug 2016 18:44:26 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id u7GGiO6l030855; Tue, 16 Aug 2016 18:44:24 +0200 Date: Tue, 16 Aug 2016 16:44:00 -0000 From: Jakub Jelinek To: Jeff Law Cc: Richard Biener , Aldy Hernandez , Martin Sebor , gcc-patches Subject: Re: protected alloca class for malloc fallback Message-ID: <20160816164424.GZ14857@tucnak.redhat.com> Reply-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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <3f8d451d-557d-fb96-7747-dea1c6540cd4@redhat.com> User-Agent: Mutt/1.5.24 (2015-08-30) X-IsSubscribed: yes X-SW-Source: 2016-08/txt/msg01203.txt.bz2 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. 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. Jakub