Re: 0005-Part-5.-Add-x86-CET-documentation

[Sandra Loosemore <sandra@codesourcery.com>]

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