On 13/02/18 10:36, Daniel P. Berrangé wrote:
On Tue, Feb 13, 2018 at 10:18:05AM +0000, Richard W.M. Jones wrote:

My build of american-fuzzy-lop fails because clang doesn't
understand the ‘-mcet -fcf-protection’ flags which seem to be
added by RPM.

   clang -O2 -g -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS 
-fexceptions -fstack-protector-strong -grecord-gcc-switches -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 
-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1 -m64 -mtune=generic -fasynchronous-unwind-tables 
-fstack-clash-protection -mcet -fcf-protection -Wall -D_FORTIFY_SOURCE=2 -g -Wno-pointer-sign 
-DAFL_PATH=\"/usr/lib64/afl\" -DBIN_PATH=\"/usr/bin\" -DVERSION=\"2.52b\"  
afl-clang-fast.c -o ../afl-clang-fast
   clang-6.0: error: unknown argument: '-mcet'
   clang-6.0: error: unknown argument: '-fcf-protection'


This suggests a bug in our RPM configuration.

Not much more info about what these flags do, but the change was recorded
here with an opaque "Intel says we need this" rationale:


Here's how the gcc 8 documentation describes -mcet:

     The '-mcet' option turns on the '-mibt' and '-mshstk' options.  The
     '-mibt' option enables indirect branch tracking support and the
     '-mshstk' option enables shadow stack support from Intel
     Control-flow Enforcement Technology (CET). The compiler also
     provides a number of built-in functions for fine-grained control in
     a CET-based application.  See *Note x86 Built-in Functions::, for
     more information.

and -fcf-protection:

     Enable code instrumentation of control-flow transfers to increase
     program security by checking that target addresses of control-flow
     transfer instructions (such as indirect function call, function
     return, indirect jump) are valid.  This prevents diverting the flow
     of control to an unexpected target.  This is intended to protect
     against such threats as Return-oriented Programming (ROP), and
     similarly call/jmp-oriented programming (COP/JOP).

     The value 'branch' tells the compiler to implement checking of
     validity of control-flow transfer at the point of indirect branch
     instructions, i.e.  call/jmp instructions.  The value 'return'
     implements checking of validity at the point of returning from a
     function.  The value 'full' is an alias for specifying both
     'branch' and 'return'.  The value 'none' turns off instrumentation.

     You can also use the 'nocf_check' attribute to identify which
     functions and calls should be skipped from instrumentation (*note
     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 '-mcet', '-mibt'
     and '-mshstk' (*note x86 Options::).

Given that -mcet seems to turn on extra instructions is this not an
issue for compatibility with older processors? or are they sequences
which decode as no-ops on older processors?


Tom Hughes (t...@compton.nu)
devel mailing list -- devel@lists.fedoraproject.org
To unsubscribe send an email to devel-le...@lists.fedoraproject.org

Reply via email to