From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129066 invoked by alias); 20 Jun 2017 08:03:31 -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 129046 invoked by uid 89); 20 Jun 2017 08:03:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.1 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=alu, rmw, H*Ad:U*jh, Hx-languages-length:1681 X-HELO: mail-ua0-f170.google.com Received: from mail-ua0-f170.google.com (HELO mail-ua0-f170.google.com) (209.85.217.170) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Tue, 20 Jun 2017 08:03:20 +0000 Received: by mail-ua0-f170.google.com with SMTP id 70so7902961uau.0 for ; Tue, 20 Jun 2017 01:03:20 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to:cc; bh=sN4Mk9ImbPO51FyAUEDBLytBmU0nSPgqH5nxq2Mr+UY=; b=cn0oauuB91Ot1EbfYmdHXt/8ABk6G5tWUOk9CPd/J7qhPebsWtV2tCGFlglyCkhxLI EVCa/f3q39HdaOFv3LISMFynYAoXTOkgL3FjgrkiEGUprW4DOBf7QvaCghhpFEDUqKAE Th4kd9aCunh5kv0v52Vc2S5uBQqBX3mtLoFJEiZA7wWqU9tj4/vsLVcIUoBMUPufLdGf DTSgG8Ej4X/i1NtcprcVGqlqztguH/WH4Ir6679LpiE3Ki5rKuFJyAwkCxZalo0IKdvL Hli7IcKScoJUjp+tm2NkNJuQA5bQUwNrhacrQlX4tzwkeWicrxePqBgljCTXupcuZKR4 Ixng== X-Gm-Message-State: AKS2vOyeeBmAfEoag0DztcZk8oUOIgWiTh055CfB6recNpif0NNSZJPA zb1vfTFYemv4UyJSOzAu413/wk0kXA== X-Received: by 10.176.16.75 with SMTP id g11mr6567169uab.40.1497945798881; Tue, 20 Jun 2017 01:03:18 -0700 (PDT) MIME-Version: 1.0 Received: by 10.103.69.29 with HTTP; Tue, 20 Jun 2017 01:03:18 -0700 (PDT) In-Reply-To: <20170619175149.GY2123@tucnak> References: <20170619172932.GV2123@tucnak> <6b026ac5-7b68-f93b-e005-17288163f442@redhat.com> <20170619175149.GY2123@tucnak> From: Uros Bizjak Date: Tue, 20 Jun 2017 08:03:00 -0000 Message-ID: Subject: Re: RFC: stack/heap collision vulnerability and mitigation with GCC To: Jakub Jelinek Cc: Jeff Law , Jan Hubicka , Eric Botcazou , gcc-patches Content-Type: text/plain; charset="UTF-8" X-SW-Source: 2017-06/txt/msg01399.txt.bz2 On Mon, Jun 19, 2017 at 7:51 PM, Jakub Jelinek wrote: > On Mon, Jun 19, 2017 at 11:45:13AM -0600, Jeff Law wrote: >> 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. > > CCing Uros and Honza here, I believe there are at least on x86 penalties > for 2-byte, maybe for 1-byte and then sometimes some stalls when you > write or read in a different size from a recent write or read. Don't use orq $0, (%rsp), as this is a high latency RMW insn. movq $0x0, (%rsp) is fast, but also quite long insn. push $0x0 increases the stack pointer for 4 or 8 bytes, depending on target word size. Push insn also updates delta stack pointer, so update of SP is required (effectively, another ALU operation) if SP is later referenced from insn other than push/pop/call/ret. There are no non-word-sized register pushes. I think that for the purpose of stack probe, we can write a byte to the end of the stack, so movb $0x0, (%rsp). This is relatively short insn, and operates in the same way for 32bit and 64bit targets. There are no issues with partial memory stalls since nothing immediately reads a different sized value from the written location. Uros.