Re: clang -mcet -fcf-protection
On 02/14/2018 08:22 PM, Richard W.M. Jones wrote: It uses both. In this case it uses clang because it has to build a clang extension (as well as a gcc extension). Isn't Clang compiled with GCC, too? (At least in the past, we didn't bootstrap it.) Why is Clang required to build the extension? (Clang is obviously needed to test the plug-in, but upstream probably has very precise ideas about the compiler flags to use for that anyway.) Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On Tue, Feb 13, 2018 at 02:27:02PM +0100, Florian Weimer wrote: > On 02/13/2018 11:36 AM, Daniel P. Berrangé wrote: > >redhat-rpm-config flags have usually been compatible with both gcc and > >clang, so if there's no newer clang that supports this, it feels like > >we've a few options > > > > 1. Have the RPM spec for apps using clang filter these flags out of > > the RPM cflags. > > 2. Revert the change in redhat-rpm-config so we're compatible with > > clang > > 3. Provide a second macro in redhat-rpm-config that is the cut down > > set of cflags which still work with clang, that apps can opt for. > > You forgot: > > 4. Compile the package with GCC (porting it if necessary). > > GCC is the Fedora system compiler, after all. This package legitimately uses clang to build a clang plugin. Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com virt-builder quickly builds VMs from scratch http://libguestfs.org/virt-builder.1.html ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On Wed, Feb 14, 2018 at 11:03:28AM -0800, Tom Stellard wrote: > On 02/13/2018 02:18 AM, 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. > > > > Is there a particular reason this packages uses clang and not gcc? It uses both. In this case it uses clang because it has to build a clang extension (as well as a gcc extension). Rich. -- Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones Read my programming and virtualization blog: http://rwmj.wordpress.com Fedora Windows cross-compiler. Compile Windows programs, test, and build Windows installers. Over 100 libraries supported. http://fedoraproject.org/wiki/MinGW ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On 02/13/2018 02:18 AM, 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. > Is there a particular reason this packages uses clang and not gcc? -Tom > 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' > > (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571) > > This suggests a bug in our RPM configuration. > > Rich. > ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedora 28)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Tue, 2018-02-13 at 10:36 +, Daniel P. Berrangé wrote: > On Tue, Feb 13, 2018 at 10:18:05AM +, 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' > > > > (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571) > > > > 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: > > https://bugzilla.redhat.com/show_bug.cgi?id=1538725 > > redhat-rpm-config flags have usually been compatible with both gcc and > clang, so if there's no newer clang that supports this, it feels like > we've a few options > > 1. Have the RPM spec for apps using clang filter these flags out of > the RPM cflags. > 2. Revert the change in redhat-rpm-config so we're compatible with > clang > 3. Provide a second macro in redhat-rpm-config that is the cut down > set of cflags which still work with clang, that apps can opt for. As long as it doesn't break builds, I don't think we need this separation. If clang is simply ignoring flags, let it do that 😉 - -- - -Igor Gnatenko -BEGIN PGP SIGNATURE- iQIzBAEBCAAdFiEEhLFO09aHZVqO+CM6aVcUvRu8X0wFAlqD3YYACgkQaVcUvRu8 X0xrhw/+IXyGgcnNd3vJoQJJr25sg23FKP/Y4iPDEFf1Le96/GM1FiFyD5vFgHsS Y5n8MQwzMpW/1QX/T8x2+EomQdnkXZG0EDG6smuOGKeEENiuAjuujULyrTQWEpr1 UychOFEdn6ZJJTUsqKn4LOlCwAvuUdvrgT/B3JyF5iFaKV6VTU76vDjoa4HjkyQY lohRWFGNamb5fTpfP2it6CcDCOBV3ABN7TVAUd/v1sXP+FjrXBVk2DBZIeoDs52W BP+ftXQaEsgdb6RN5IStvQ4d4TOcmEjun3bPzUU8w2ldPGJfJ6QPyrj0Tvye18XC gDrVbjKvFQdZAFNYWWO5SEakb3ZWgzKzUHAi2MOZNcA4D+hgny0E+uPPdq5O6qnc KlFM7QZTpQO9oZAqvn/2EDI10XJdzXPVVtp992Vbgm01nDuVhr6XeaKbyEnBErk5 pE1/voR5Vw8Cx5nu+yFBrn6VPSQVJFjs+iY5DOH0jS2WAF9J9npIsTl0FdpsaaWC Uzu6Q3KwQs4TEoF5Xn/Z98gt/tUb5QK2meQfUz55Arm1x4Zp5KigaHUv99lpBP5n sixBJS54rorf0LlK+Fi6jglrJAIdXMCvlJ4NIUms5gN6OCaoshO5baKu7vCv26uc 44yvhaVupmYJDwyB/UG6KuxsCPLyzQ7HEMRUhNfXJ++QYkCVPAM= =frLg -END PGP SIGNATURE- ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On Tuesday, 13 February 2018 at 14:27, Florian Weimer wrote: > On 02/13/2018 11:36 AM, Daniel P. Berrangé wrote: > > redhat-rpm-config flags have usually been compatible with both gcc and > > clang, so if there's no newer clang that supports this, it feels like > > we've a few options > > > > 1. Have the RPM spec for apps using clang filter these flags out of > > the RPM cflags. > > 2. Revert the change in redhat-rpm-config so we're compatible with > > clang > > 3. Provide a second macro in redhat-rpm-config that is the cut down > > set of cflags which still work with clang, that apps can opt for. > > You forgot: > > 4. Compile the package with GCC (porting it if necessary). > > GCC is the Fedora system compiler, after all. The Packaging Guidelines say this, too: https://fedoraproject.org/wiki/Packaging:Guidelines#Compiler Regards, Dominik -- Fedora https://getfedora.org | RPMFusion http://rpmfusion.org There should be a science of discontent. People need hard times and oppression to develop psychic muscles. -- from "Collected Sayings of Muad'Dib" by the Princess Irulan ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On 02/13/2018 11:36 AM, Daniel P. Berrangé wrote: redhat-rpm-config flags have usually been compatible with both gcc and clang, so if there's no newer clang that supports this, it feels like we've a few options 1. Have the RPM spec for apps using clang filter these flags out of the RPM cflags. 2. Revert the change in redhat-rpm-config so we're compatible with clang 3. Provide a second macro in redhat-rpm-config that is the cut down set of cflags which still work with clang, that apps can opt for. You forgot: 4. Compile the package with GCC (porting it if necessary). GCC is the Fedora system compiler, after all. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On 02/13/2018 11:46 AM, Tom Hughes wrote: 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? They are NOPs on all current CPUs. They trap on some older CPUs, but we coordinated this change with the x86 SIG to make sure that it matches their requirements. Thanks, Florian ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On Tue, Feb 13, 2018 at 10:46:37AM +, Tom Hughes wrote: > 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? https://software.intel.com/sites/default/files/managed/4d/2a/control-flow-enforcement-technology-preview.pdf The instructions are NOPs on older CPUs. Jakub ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection
On 13/02/18 10:36, Daniel P. Berrangé wrote: On Tue, Feb 13, 2018 at 10:18:05AM +, 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' (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571) 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: https://bugzilla.redhat.com/show_bug.cgi?id=1538725 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: '-fcf-protection=[full|branch|return|none]' 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 -- Tom Hughes (t...@compton.nu) http://compton.nu/ ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
Re: clang -mcet -fcf-protection (was: Re: Mass Rebuild for Fedora 28)
On Tue, Feb 13, 2018 at 10:18:05AM +, 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' > > (https://koji.fedoraproject.org/koji/taskinfo?taskID=25000571) > > 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: https://bugzilla.redhat.com/show_bug.cgi?id=1538725 redhat-rpm-config flags have usually been compatible with both gcc and clang, so if there's no newer clang that supports this, it feels like we've a few options 1. Have the RPM spec for apps using clang filter these flags out of the RPM cflags. 2. Revert the change in redhat-rpm-config so we're compatible with clang 3. Provide a second macro in redhat-rpm-config that is the cut down set of cflags which still work with clang, that apps can opt for. Regards, Daniel -- |: https://berrange.com -o-https://www.flickr.com/photos/dberrange :| |: https://libvirt.org -o-https://fstop138.berrange.com :| |: https://entangle-photo.org-o-https://www.instagram.com/dberrange :| ___ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org
