This is the mail archive of the
mailing list for the GCC project.
Re: Should CET be enabled by default in GCC8
- From: "H.J. Lu" <hjl dot tools at gmail dot com>
- To: Jakub Jelinek <jakub at redhat dot com>
- Cc: Richard Biener <rguenther at suse dot de>, Uros Bizjak <ubizjak at gmail dot com>, GCC Development <gcc at gcc dot gnu dot org>, "Tsimbalist, Igor V" <igor dot v dot tsimbalist at intel dot com>
- Date: Wed, 18 Apr 2018 04:29:19 -0700
- Subject: Re: Should CET be enabled by default in GCC8
- References: <CAFULd4aNY_N7dVMOxS7d9s2=kWPxrtrNTz_h-jgkvi9Drd4Pcw@mail.gmail.com> <alpine.LSU.email@example.com> <20180418103407.GQ8577@tucnak>
On Wed, Apr 18, 2018 at 3:34 AM, Jakub Jelinek <firstname.lastname@example.org> wrote:
> On Wed, Apr 18, 2018 at 12:30:03PM +0200, Richard Biener wrote:
>> On Wed, 18 Apr 2018, Uros Bizjak wrote:
>> > Hello!
>> > Currently, CET is enabled by default for linux if target supports
>> > multi-byte NOPs and if assembler supports CET insn. Effectively, with
>> > newer binutils, CET support is an opt-out feature.
>> > I don't think this should be the case, and I propose to consider CET
>> > as an opt-in feature. Multi-byte NOPs have non-zero cost (at least
>> > they increase the binary). If someone wants to enable the feature, it
>> > can be done in less surprising way to --enable-cet during configure
>> > time.
>> > I'd like to hear the opinion of RMs, if CET should remain to be an
>> > opt-out feature by default?
>> My personal opinion is that CET should be opt-in (I explicitely
>> disable it for SUSE). I'm not sure if it doesn't go the way MPX
> I agree it should be opt-in, have said that in the past already.
> In Fedora it will not make a difference, as the whole distro is
> built with -mcet -fcf-protection on i?86/x86_64.
I submitted a patch to add -mnop to enable multi-byte NOP code
generation which can be used with -fcf-protection to implement
indirect branch and return address tracking without -mcet: