From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 62478 invoked by alias); 29 Sep 2017 05:15:37 -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 62264 invoked by uid 89); 29 Sep 2017 05:15:25 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-24.6 required=5.0 tests=AWL,BAYES_00,GIT_PATCH_0,GIT_PATCH_1,GIT_PATCH_2,GIT_PATCH_3,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=gol X-HELO: relay1.mentorg.com Received: from relay1.mentorg.com (HELO relay1.mentorg.com) (192.94.38.131) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Fri, 29 Sep 2017 05:15:20 +0000 Received: from svr-orw-mbx-03.mgc.mentorg.com ([147.34.90.203]) by relay1.mentorg.com with esmtps (TLSv1.2:ECDHE-RSA-AES256-SHA384:256) id 1dxndu-0005gZ-J8 from Sandra_Loosemore@mentor.com ; Thu, 28 Sep 2017 22:15:18 -0700 Received: from [127.0.0.1] (147.34.91.1) by svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) with Microsoft SMTP Server (TLS) id 15.0.1263.5; Thu, 28 Sep 2017 22:15:16 -0700 Subject: Re: 0005-Part-5.-Add-x86-CET-documentation To: "Tsimbalist, Igor V" , Uros Bizjak References: <59C87B61.4010400@codesourcery.com> <59CB1DB9.1010700@codesourcery.com> CC: "gcc-patches@gcc.gnu.org" From: Sandra Loosemore Message-ID: <59CDD6E3.3040309@codesourcery.com> Date: Fri, 29 Sep 2017 05:15:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.5.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-ClientProxiedBy: SVR-ORW-MBX-05.mgc.mentorg.com (147.34.90.205) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-SW-Source: 2017-09/txt/msg01926.txt.bz2 On 09/27/2017 09:17 AM, Tsimbalist, Igor V wrote: > Updated version #3. > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index e52a1ea..accba40 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -5655,6 +5655,14 @@ compiled with the @option{-fcf-protection=branch} option. The > compiler assumes that the function's address is a valid target for a > control-flow transfer. > > +@emph{x86 implementation:} when @option{-fcf-protection} option is > +specified the compiler inserts an @code{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 where @code{endbr} instruction was inserted > +is valid. > + I think the consensus among Joseph, Jeff, and I is that this doesn't belong in the GCC manual at all, but in the ABI documentation. So please delete the implementation note. > @@ -5662,7 +5670,9 @@ not be instrumented when compiled with the > that the function's address from the pointer is a valid target for > a control-flow transfer. A direct function call through a function > name is assumed to be a safe call thus direct calls are not > -instrumented by the compiler. > +instrumented by the compiler. For @emph{x86 implementation} the > +compiler inserts a @code{notrack} prefix before an indirect call > +instruction. Ditto with this implementation note. > diff --git a/gcc/doc/invoke.texi b/gcc/doc/invoke.texi > index c4faa23..189130b 100644 > --- a/gcc/doc/invoke.texi > +++ b/gcc/doc/invoke.texi > @@ -1203,6 +1203,7 @@ See RS/6000 and PowerPC Options. > -msse4a -m3dnow -m3dnowa -mpopcnt -mabm -mbmi -mtbm -mfma4 -mxop @gol > -mlzcnt -mbmi2 -mfxsr -mxsave -mxsaveopt -mrtm -mlwp -mmpx @gol > -mmwaitx -mclzero -mpku -mthreads @gol > +-mcet -mibt -mshstk @gol > -mms-bitfields -mno-align-stringops -minline-all-stringops @gol > -minline-stringops-dynamically -mstringop-strategy=@var{alg} @gol > -mmemcpy-strategy=@var{strategy} -mmemset-strategy=@var{strategy} @gol > @@ -11374,6 +11375,14 @@ You can also use the @code{nocf_check} attribute to identify > which functions and calls should be skipped from instrumentation > (@pxref{Function Attributes}). > > +Currently the x86 GNU/Linux target provides an implementation based > +on Intel Control-flow Enforcement Technology (CET). Instrumentation > +for x86 is controlled by target-specific options @option{-mcet}, > +@option{-mibt} and @option{-mshstk} (@pxref{x86 Options}). This part is OK. > +The compiler also provides a number of built-in functions for > +fine-grained control in a CET-based application. > +See @xref{x86 Built-in Functions}, for more information. I think these builtins emit instructions in the CET extension explicitly and don't affect the GCC's code generation for the -fcf-protection option. So please move this to the discussion of -mcet in the x86 options section instead.... > @@ -25779,6 +25792,11 @@ supported architecture, using the appropriate flags. In particular, > the file containing the CPU detection code should be compiled without > these options. > > +The @option{-mcet} option turns on the @option{-mibt} and @option{-mshstk} > +options. The @option{-mibt} option enables indirect branch tracking support > +and the @option{-mshstk} option enables shadow stack support from > +Intel Control-flow Enforcement Technology (CET). > + ...here. The patch is OK with those changes. -Sandra