This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
- From: "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>
- Date: Fri, 15 Sep 2017 11:12:40 +0000
- Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
- Authentication-results: sourceware.org; auth=none
- References: <D511F25789BA7F4EBA64C8A63891A0027AA04014@IRSMSX102.ger.corp.intel.com> <CAFiYyc0=pkpVTSX9W7YZmPo19StCHsPK7PMmO29QmQ8XPCFvxg@mail.gmail.com> <D511F25789BA7F4EBA64C8A63891A0027AA583B9@IRSMSX102.ger.corp.intel.com> <CAFiYyc0YrTPySyhegPU83g70B5-kVt95AVW2p8bfMLyM0BSyCQ@mail.gmail.com>
> -----Original Message-----
> From: Tsimbalist, Igor V
> Sent: Tuesday, September 12, 2017 5:35 PM
> To: 'Richard Biener' <richard.guenther@gmail.com>
> Cc: 'gcc-patches@gcc.gnu.org' <gcc-patches@gcc.gnu.org>; Tsimbalist, Igor V
> <igor.v.tsimbalist@intel.com>
> Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
>
> > -----Original Message-----
> > From: Tsimbalist, Igor V
> > Sent: Friday, August 18, 2017 4:43 PM
> > To: 'Richard Biener' <richard.guenther@gmail.com>
> > Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V
> > <igor.v.tsimbalist@intel.com>
> > Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> >
> > > -----Original Message-----
> > > From: Richard Biener [mailto:richard.guenther@gmail.com]
> > > Sent: Friday, August 18, 2017 3:53 PM
> > > To: Tsimbalist, Igor V <igor.v.tsimbalist@intel.com>
> > > Cc: gcc-patches@gcc.gnu.org
> > > Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> > >
> > > On Fri, Aug 18, 2017 at 3:11 PM, Tsimbalist, Igor V
> > > <igor.v.tsimbalist@intel.com> wrote:
> > > >> -----Original Message-----
> > > >> From: Richard Biener [mailto:richard.guenther@gmail.com]
> > > >> Sent: Tuesday, August 15, 2017 3:43 PM
> > > >> To: Tsimbalist, Igor V <igor.v.tsimbalist@intel.com>
> > > >> Cc: gcc-patches@gcc.gnu.org
> > > >> Subject: Re: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling
> > > >>
> > > >> On Tue, Aug 1, 2017 at 10:56 AM, Tsimbalist, Igor V
> > > >> <igor.v.tsimbalist@intel.com> wrote:
> > > >> > Part#1. Add generic part for Intel CET enabling.
> > > >> >
> > > >> > The spec is available at
> > > >> >
> > > >> > https://software.intel.com/sites/default/files/managed/4d/2a/co
> > > >> > nt ro l-f low-enforcement-technology-preview.pdf
<..skipped..>
> > > >> I think 'notrack' is somewhat unspecific of a name, what
> > > >> prevented you to use 'nocet'?
> > > >
> > > > Actually it's specific. The HW will have a prefix with exactly
> > > > this name and
> > > the same meaning. And I think, what is more important, 'track/notrack'
> > > gives better semantic for a user. CET is a name bound with Intel
> > > specific technology.
> > >
> > > But 'tracking' something is quite unspecific. Tracking for what?
> > > 'no_verify_cf' (aka do not verify control flow) maybe?
> >
> > The name just has to suggest the right semantic. 'no_verify_cf' is
> > good, let's use it unless different name appears.
> I have renamed all newly introduced function and macro names to use
> 'noverify_cf'. But I still keep the attribute name as 'notrack'. Historically the
> attribute name follows the public CET specification, which uses 'no-track
> prefix' wording. Is it ok to keep such attribute name?
Here is an updated proposal about option name and attribute name.
The new option has values to let a user to choose what control-flow protection to activate.
-fcf-protection=[full|branch|return|none]
branch - do control-flow protection for indirect jumps and calls
return - do control-flow protection for function returns
full - alias to specify both branch + return
none - turn off protection. This value is needed when/if cf-protection is turned on by default by driver in future
Attribute name is the most tough one. Here are several names to evaluate: 'nocf_verify' or 'nocf_check', or to be more specific and to mimic option name 'nocf_branch_verify' or 'nocf_branch_check'. I would prefer 'nocf_check' as it applies to functions and function pointers so it's definitely related to a branch and it's a smaller one.
If you ok with the new proposal I'll implement it in a general parts (code, documentation and tests) and resend these patches for review.
Thanks,
Igor