From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 108902 invoked by alias); 27 Sep 2017 03:40: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 108637 invoked by uid 89); 27 Sep 2017 03:40:49 -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=bmi, H*u:38.0, H*UA:38.0 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; Wed, 27 Sep 2017 03:40:47 +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 1dx3DJ-0006AW-9e from Sandra_Loosemore@mentor.com ; Tue, 26 Sep 2017 20:40:45 -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; Tue, 26 Sep 2017 20:40:42 -0700 Subject: Re: 0005-Part-5.-Add-x86-CET-documentation To: "Tsimbalist, Igor V" , Uros Bizjak References: <59C87B61.4010400@codesourcery.com> CC: "gcc-patches@gcc.gnu.org" From: Sandra Loosemore Message-ID: <59CB1DB9.1010700@codesourcery.com> Date: Wed, 27 Sep 2017 03:40: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-03.mgc.mentorg.com (147.34.90.203) To svr-orw-mbx-03.mgc.mentorg.com (147.34.90.203) X-SW-Source: 2017-09/txt/msg01792.txt.bz2 On 09/26/2017 07:47 AM, Tsimbalist, Igor V wrote: > Here is a new version of the patch. > > diff --git a/gcc/doc/extend.texi b/gcc/doc/extend.texi > index a374890..a900ed1 100644 > --- a/gcc/doc/extend.texi > +++ b/gcc/doc/extend.texi > @@ -5655,6 +5655,13 @@ 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 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. > @@ -5662,7 +5669,8 @@ 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 NOTRACK prefix before an indirect call instruction. Likewise here. > @@ -21217,6 +21225,25 @@ void __builtin_ia32_wrpkru (unsigned int) > unsigned int __builtin_ia32_rdpkru () > @end smallexample > > +The following built-in functions are available when @option{-mcet} is used. > +They are used to support Intel Control-flow Enforcment Technology (CET). > +Each built-in function generate a machine instruction that is part of the s/generate a/generates the/ > @@ -11378,6 +11379,20 @@ You can also use the @code{nocf_check} attribute to identify > which functions and calls should be skipped from instrumentation > (@pxref{Function Attributes}). > > +Currently x86 GNU/Linux target provides an implementation based on s/x86/the x86/ > +Intel Control-flow Enforcement Technology (CET), thus @option{-mcet} s/@option/the @option/ > +option is required to enable this feature. I think you should put a cross-reference to the x86 options node here, and move all the following x86-specific discussion to that section. > In order to get an > +application to be CET compatible the x86 implementation requires > +all object files have to be compiled with > +@option{-fcf-protection} option and all linked in libraries have > +to be CET compatible. I'm having difficulty parsing this. What does "CET compatible" mean? Is this an ABI compatibility issue, so that all objects linked into the executable have to be compiled with the (same?) @option{-fcf-protection} option if any of them do? Or do you just lose checking on code in uninstrumented objects? > +Instrumentation for x86 is controlled by target specific options hyphenate target-specific here > +@option{-mcet}, @option{-mibt} and @option{-mshstk}. The compiler > +also provides a number of built-in functions for fine-grained control > +of CET-based implementation. See @xref{x86 Built-in Functions}, > +for more information. > + > @item -fstack-protector > @opindex fstack-protector > Emit extra code to check for buffer overflows, such as stack smashing > @@ -25755,15 +25770,19 @@ preferred alignment to @option{-mpreferred-stack-boundary=2}. > @need 200 > @itemx -mclzero > @opindex mclzero > +@need 200 > @itemx -mpku > @opindex mpku > +@need 200 > +@itemx -mcet > +@opindex mcet > These switches enable the use of instructions in the MMX, SSE, > SSE2, SSE3, SSSE3, SSE4.1, AVX, AVX2, AVX512F, AVX512PF, AVX512ER, AVX512CD, > SHA, AES, PCLMUL, FSGSBASE, RDRND, F16C, FMA, SSE4A, FMA4, XOP, LWP, ABM, > AVX512VL, AVX512BW, AVX512DQ, AVX512IFMA AVX512VBMI, BMI, BMI2, FXSR, > -XSAVE, XSAVEOPT, LZCNT, RTM, MPX, MWAITX, PKU, 3DNow!@: or enhanced 3DNow!@: > -extended instruction sets. Each has a corresponding @option{-mno-} option > -to disable use of these instructions. > +XSAVE, XSAVEOPT, LZCNT, RTM, MPX, MWAITX, PKU, IBT, SHSTK, > +3DNow!@: or enhanced 3DNow!@: extended instruction sets. Each has a > +corresponding @option{-mno-} option to disable use of these instructions. > > These extensions are also available as built-in functions: see > @ref{x86 Built-in Functions}, for details of the functions enabled and > @@ -25783,6 +25802,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 @option{-mibt} and @option{-mshstk} s/turns on/turns on the/ > +options. @option{-mibt} option enables idirect branch tracking support s/@option/The @option/ s/idirect/indirect/ > +and @option{-mshstk} option enables shadow stack support from s/@option/the @option/ > +Intel Control-flow Enforcement Technology (CET). > + > @item -mdump-tune-features > @opindex mdump-tune-features > This option instructs GCC to dump the names of the x86 performance > @@ -25856,6 +25880,24 @@ see @ref{Other Builtins} for details. > This option enables use of the @code{movbe} instruction to implement > @code{__builtin_bswap32} and @code{__builtin_bswap64}. > > +@item -mibt > +@opindex mibt > +This option tells the compiler to use indirect branch tracking support > +(for indirect calls and jumps) from x86 Control-flow Enforcement > +Technology (CET). The option has effect only if > +@option{-fcf-protection=full} or @option{-fcf-protection=branch} option > +is specified. The option @option{-mibt} is on by default when @code{-mcet} s/@code{-mcet}/the @option{-mcet}/ > +option is specified. > + > +@item -mshstk > +@opindex mshstk > +This option tells the compiler to use shadow stack support (return > +address tracking) from x86 Control-flow Enforcement Technology (CET). > +The option has effect only if @option{-fcf-protection=full} or > +@option{-fcf-protection=return} option is specified. The option > +@option{-mshstk} is on by default when @option{-mcet} option is > +specified. > + > @item -mcrc32 > @opindex mcrc32 > This option enables built-in functions @code{__builtin_ia32_crc32qi}, -Sandra