From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26104 invoked by alias); 20 Jun 2017 20:37:52 -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 26076 invoked by uid 89); 20 Jun 2017 20:37:51 -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,SPF_PASS autolearn=ham version=3.3.2 spammy=H*Ad:D*nyu.edu, H*Ad:U*kenner X-HELO: smtp.eu.adacore.com Received: from mel.act-europe.fr (HELO smtp.eu.adacore.com) (194.98.77.210) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Jun 2017 20:37:50 +0000 Received: from localhost (localhost [127.0.0.1]) by filtered-smtp.eu.adacore.com (Postfix) with ESMTP id AC3DD81464; Tue, 20 Jun 2017 22:37:48 +0200 (CEST) Received: from smtp.eu.adacore.com ([127.0.0.1]) by localhost (smtp.eu.adacore.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id p1ZyOY__tIkq; Tue, 20 Jun 2017 22:37:48 +0200 (CEST) Received: from polaris.localnet (bon31-6-88-161-99-133.fbx.proxad.net [88.161.99.133]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.eu.adacore.com (Postfix) with ESMTPSA id 7324E8145A; Tue, 20 Jun 2017 22:37:48 +0200 (CEST) From: Eric Botcazou To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org, Richard Kenner , law@redhat.com Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC Date: Tue, 20 Jun 2017 20:37:00 -0000 Message-ID: <2839350.GqtxodeRKm@polaris> User-Agent: KMail/4.14.10 (Linux/3.16.7-53-desktop; KDE/4.14.9; x86_64; ; ) In-Reply-To: <20170620194818.GL2123@tucnak> References: <1668482.ocPt5K0QLh@polaris> <20170620194818.GL2123@tucnak> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-SW-Source: 2017-06/txt/msg01509.txt.bz2 > But then valgrind won't be able to find bugs in the code (storing and later > reading stuff into the volatile parts of the stack that could be overwritten > by any asynchronous signal). GCC had various bugs in this area and > valgrind has been able to report those. Unless the probe instruction is > sufficiently magic that it won't usually appear in other code. Right, maybe this magic aspect was the reason why it was initially implemented like that for Cygwin, at least you know that orl $0 is meant to be special. > Only checking loads below the stack is not sufficient, some buggy code could > e.g. store some data below stack pointer (below red zone if any), then > subtract stack and then try to read it, etc. > > Not to mention that it isn't just false positive messages with current > valgrind on -fstack-check code, e.g. on ppc64 it just crashes. The reasoning seems weird though since, apart from x86/x86-64, you're going to gratuitously inflict this painful "moving sp" thing to every program compiled on Linux because of just one tool that you can adapt. -- Eric Botcazou