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
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
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 -- email@example.com
To unsubscribe send an email to devel-le...@lists.fedoraproject.org