From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19409 invoked by alias); 20 Jul 2014 20:37:58 -0000 Mailing-List: contact gcc-help-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-help-owner@gcc.gnu.org Received: (qmail 19233 invoked by uid 89); 20 Jul 2014 20:37:50 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham version=3.3.2 X-HELO: ioooi.vinc17.net Received: from ioooi.vinc17.net (HELO ioooi.vinc17.net) (92.243.22.117) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Sun, 20 Jul 2014 20:37:48 +0000 Received: from smtp-xvii.vinc17.net (AAnnecy-651-1-26-219.w86-209.abo.wanadoo.fr [86.209.9.219]) by ioooi.vinc17.net (Postfix) with ESMTPSA id EE24E73; Sun, 20 Jul 2014 22:37:44 +0200 (CEST) Received: by xvii.vinc17.org (Postfix, from userid 1000) id 243FB21A079; Sun, 20 Jul 2014 22:37:43 +0200 (CEST) Date: Sun, 20 Jul 2014 20:37:00 -0000 From: Vincent Lefevre To: gcc-help@gcc.gnu.org Subject: Re: Silent stack-heap collision under GNU/Linux Message-ID: <20140720203742.GA13303@xvii.vinc17.org> Mail-Followup-To: gcc-help@gcc.gnu.org References: <20140720174911.GE7776@xvii.vinc17.org> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.21-6305-vl-r59709 (2013-04-16) X-IsSubscribed: yes X-SW-Source: 2014-07/txt/msg00078.txt.bz2 On 2014-07-20 12:04:43 -0700, Ian Lance Taylor wrote: > On Sun, Jul 20, 2014 at 10:49 AM, Vincent Lefevre > wrote: > > It appears that GCC can generate code that yields silent stack-heap > > collision under GNU/Linux. I mean, the program doesn't crash (at least > > not immediately), the memory just gets corrupted. At the same time, > > this overrides the stack-size limit defined at the kernel level > > (getrlimit system call / RLIMIT_STACK) because the kernel has no > > chance to detect the collision (no page fault); thus this limit > > doesn't protect the user, and the problem seems to be on GCC's side. > > > > Why aren't such collisions detected by default? > > Because it's expensive, [...] Really? This takes only a few instructions, doesn't it? And AFAIK, the detection is needed only when the stack pointer decrement is important (the problem occurs only when unmapped memory after the stack is skipped). In most cases, VLA's are not used and GCC should be able to determine an upper bound on the stack pointer decrement, thus avoiding generating this detection on functions that don't need it. > > How can one tell GCC to detect them? > > Use the -fstack-check option. [...] Thanks, I hadn't tried this one. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)