From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 45124 invoked by alias); 19 Feb 2016 19:58:47 -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 45114 invoked by uid 89); 19 Feb 2016 19:58:46 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.8 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 spammy=imperfect, Hx-languages-length:1004 X-HELO: zimbra.cs.ucla.edu Subject: Re: [PATCH v2 0/3] posix: Execute file function fixes To: Adhemerval Zanella , libc-alpha@sourceware.org References: <1455905134-21014-1-git-send-email-adhemerval.zanella@linaro.org> <56C75FE3.2030606@cs.ucla.edu> <56C769A9.6080301@linaro.org> From: Paul Eggert Message-ID: <56C773F2.5000608@cs.ucla.edu> Date: Fri, 19 Feb 2016 19:58:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.0 MIME-Version: 1.0 In-Reply-To: <56C769A9.6080301@linaro.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2016-02/txt/msg00546.txt.bz2 On 02/19/2016 11:14 AM, Adhemerval Zanella wrote: > I do not agree it is a regression since it fixes two important issues: > exec async-signal-safeness and vfork usage. Even if a change makes improvements in some ways, the change can still be a regression in other ways. The proposed change plainly has such regressions. > the vector of attack might be limited Agreed. Still, the vector is there. > The current '__libc_use_alloca' is a fragile and arbitrary stack > control flow and since it does not track total stack usage against > runtime imposed limit it does not add anything related to security. Certainly __libc_use_alloca is an imperfect mechanism. However, if code touches buffers before going past them, __libc_use_alloca results in reliable stack overflow protection in the common case where sufficiently-large guard pages are at the top of the stack. So it's an exaggeration to say that __libc_use_alloca adds nothing to security.