From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 119847 invoked by alias); 27 Sep 2017 08:52:27 -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 119837 invoked by uid 89); 27 Sep 2017 08:52:27 -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,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=Hx-languages-length:1505, transfer 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; Wed, 27 Sep 2017 08:52:26 +0000 Received: from smtp.corp.redhat.com (int-mx01.intmail.prod.int.phx2.redhat.com [10.5.11.11]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 6CEF85F7B1; Wed, 27 Sep 2017 08:52:24 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 6CEF85F7B1 Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx10.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com Received: from oldenburg.str.redhat.com (ovpn-117-81.ams2.redhat.com [10.36.117.81]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 84B737EE6F; Wed, 27 Sep 2017 08:52:23 +0000 (UTC) Subject: Re: 0005-Part-5.-Add-x86-CET-documentation To: Sandra Loosemore , "Tsimbalist, Igor V" , Uros Bizjak Cc: "gcc-patches@gcc.gnu.org" References: <59C87B61.4010400@codesourcery.com> <59CB1DB9.1010700@codesourcery.com> From: Florian Weimer Message-ID: Date: Wed, 27 Sep 2017 08:52:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <59CB1DB9.1010700@codesourcery.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-09/txt/msg01802.txt.bz2 On 09/27/2017 05:40 AM, Sandra Loosemore wrote: >> >> +@emph{x86 implementation:} when @option{-fcf-protection} option is >> +specified the compiler inserts an ENDBR instruction at function's >> +prologue if the function's type does not have the @code{nocf_check} >> +attribute and addresses to which indirect control-flow transfer can >> +happen.  The instruction triggers the HW check if a control-flow >> +transfer to the address of ENDBR instruction is valid. > > Implementation details like this should be comments in the code, not > included in the user-facing documentation. This is part of the ABI GCC implements, so it has to be documented somewhere, and not just as part of the GCC source code. CET is not properly described in the ABI supplement and I don't think this will change, so detailed documentation in the GCC manual is very much desirable. That being said, the implementation notes above need some clarification. It's not clear to me what the conditions are under which the ENDBR instruction is emitted (and we probably should use @code{endbr} in the manual), what it is trying to achieve, and how the x86 calling convention changes. I assume it is somehow related to what we call internally “the suffix problem”: without control flow integrity, an attacker might skip over precondition/hardening checks, directly to the critical changes we want to protect, executing only the suffix of a function (hence the name). Thanks, Florian