On Fri, Sep 15, 2017 at 1:12 PM, Tsimbalist, Igor V <igor.v.tsimbal...@intel.com> wrote: >> -----Original Message----- >> From: Tsimbalist, Igor V >> Sent: Tuesday, September 12, 2017 5:35 PM >> To: 'Richard Biener' <richard.guent...@gmail.com> >> Cc: 'gcc-patches@gcc.gnu.org' <gcc-patches@gcc.gnu.org>; Tsimbalist, Igor V >> <igor.v.tsimbal...@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.guent...@gmail.com> >> > Cc: gcc-patches@gcc.gnu.org; Tsimbalist, Igor V >> > <igor.v.tsimbal...@intel.com> >> > Subject: RE: 0001-Part-1.-Add-generic-part-for-Intel-CET-enabling >> > >> > > -----Original Message----- >> > > From: Richard Biener [mailto:richard.guent...@gmail.com] >> > > Sent: Friday, August 18, 2017 3:53 PM >> > > To: Tsimbalist, Igor V <igor.v.tsimbal...@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.tsimbal...@intel.com> wrote: >> > > >> -----Original Message----- >> > > >> From: Richard Biener [mailto:richard.guent...@gmail.com] >> > > >> Sent: Tuesday, August 15, 2017 3:43 PM >> > > >> To: Tsimbalist, Igor V <igor.v.tsimbal...@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.tsimbal...@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.
nocf_check sounds fine to me. Richard. > Thanks, > Igor >
