From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119860 invoked by alias); 19 Jun 2017 17:45:50 -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 110347 invoked by uid 89); 19 Jun 2017 17:45:20 -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,SPF_HELO_PASS,T_RP_MATCHES_RCVD autolearn=ham version=3.3.2 spammy=dropping, Hx-languages-length:1827 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; Mon, 19 Jun 2017 17:45:18 +0000 Received: from smtp.corp.redhat.com (int-mx04.intmail.prod.int.phx2.redhat.com [10.5.11.14]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 9A396C001F3B; Mon, 19 Jun 2017 17:45:16 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 9A396C001F3B Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx07.extmail.prod.ext.phx2.redhat.com; spf=pass smtp.mailfrom=law@redhat.com DKIM-Filter: OpenDKIM Filter v2.11.0 mx1.redhat.com 9A396C001F3B Received: from localhost.localdomain (ovpn-117-122.phx2.redhat.com [10.3.117.122]) by smtp.corp.redhat.com (Postfix) with ESMTP id 4FFE1179E3; Mon, 19 Jun 2017 17:45:15 +0000 (UTC) Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC To: Jakub Jelinek , Eric Botcazou Cc: gcc-patches References: <20170619172932.GV2123@tucnak> From: Jeff Law Message-ID: <6b026ac5-7b68-f93b-e005-17288163f442@redhat.com> Date: Mon, 19 Jun 2017 17:45:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.1.0 MIME-Version: 1.0 In-Reply-To: <20170619172932.GV2123@tucnak> Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-06/txt/msg01352.txt.bz2 On 06/19/2017 11:29 AM, Jakub Jelinek wrote: > > Also, on i?86 orq $0, (%rsp) or orl $0, (%esp) is used to probe stack, > while it is shorter, is it actually faster or as slow as movq $0, (%rsp) > or movl $0, (%esp) ? Florian raised this privately to me as well. THere's a couple issues. 1. Is there a performance penalty/gain for sub-word operations? If not, we can improve things slighly there. Even if it's performance neutral we can probably do better on code size. 2. I would *prefer* if the probe actually changed the value, and the more destructive, the better :-0 It allows catching something gone wild easier. These are pretty minor implementation details IMHO, but now is a good time to revisit the probe style. I'm mostly concerned about holes in the basic probing strategy, how we're going to deal with the additional architectures (I can't imagine we'll want to go through the pain of a custom implementation for each target) and the UI. On the last topic. When we first started this work, it appeared like we could make most targets with -fstack-check=specific support work (possibly with some inefficiency) by just dropping the probe-ahead-of-need aspects of the existing implementation. ie, we'd drop the requirement for being able to run the signal handler and stop probing 2 pages beyond the current stack requirements and instead just probe up to what the current function needed. This felt like a "probing policy" (ahead-of-need vs as-needed). But when we ran into the issues with valgrind it became clear that we really couldn't safely use the current port support for -fstack-check=specific. Thus I find myself rethinking is this a probing policy option or should it just be another variant of -fstack-check=. Jeff