From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21166 invoked by alias); 21 Nov 2014 17:22:13 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 21152 invoked by uid 89); 21 Nov 2014 17:22:12 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_NONE autolearn=ham version=3.3.2 X-HELO: relay1.mentorg.com Date: Fri, 21 Nov 2014 17:22:00 -0000 From: Joseph Myers To: Leonhard Holz CC: Subject: Re: [RFC][BZ #16009] Memory handling in strxfrm_l() In-Reply-To: <546F12A3.5030204@web.de> Message-ID: References: <546DCC25.4020808@web.de> <20141121040317.GT22465@brightrain.aerifal.cx> <546F12A3.5030204@web.de> User-Agent: Alpine 2.10 (DEB 1266 2009-07-14) MIME-Version: 1.0 Content-Type: text/plain; charset="US-ASCII" X-SW-Source: 2014-11/txt/msg00607.txt.bz2 On Fri, 21 Nov 2014, Leonhard Holz wrote: > I took a look at __libc_use_alloca and it's just > > extern inline int __libc_use_alloca (size_t size) > { > return size <= __MAX_ALLOCA_CUTOFF; > } > > Should'nt it consider the currently used stack size to see if there is enough > stack memory left? Or do I have a too simple idea of OS stack memory > handling... The security requirement is simply that pages up to __MAX_ALLOCA_CUTOFF (plus non-alloca stack requirements) beyond the current stack pointer must either be available for the stack, or must be unmapped so that attempted writes to them result in a fatal signal - that alloca can't overflow from the stack into other allocated and writable memory regions. I don't know what guarantees are provided in this regard by the Linux kernel / glibc's allocation of thread stacks. -- Joseph S. Myers joseph@codesourcery.com