[Bug target/104713] New: gcc does not reject -march=i686 -fcf-protection

[Bug target/104713] New: gcc does not reject -march=i686 -fcf-protection

[bunk at stusta dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

            Bug ID: 104713
           Summary: gcc does not reject -march=i686 -fcf-protection
           Product: gcc
           Version: 11.2.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bunk at stusta dot de
  Target Milestone: ---

To support the Geode in OLPC, the toolchain definition of i686 does include
CMOV but it does not include multi-byte NOPs.

https://bugs.debian.org/1004894 is due to autodetection for -fcf-protection
that incorrectly succeeds with -march=i686.

The bug is likely in
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-options.cc;h=805539364108eee07f5bda527acd6f39f3f7bf95;hb=HEAD#l2929

A similar problem in a different place was bug 84148.

Testcase:
$ touch test.c
$ gcc -m32 -march=i586 -fcf-protection -c test.c
cc1: error: ‘-fcf-protection’ is not compatible with this target
$ gcc -m32 -march=i686 -fcf-protection -c test.c
$

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[pinskia at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Is OLPC really still around? I thought it died when Google came out with their
chrome books.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[bunk at stusta dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

--- Comment #2 from Adrian Bunk <bunk at stusta dot de> ---
(In reply to Andrew Pinski from comment #1)
> Is OLPC really still around? I thought it died when Google came out with
> their chrome books.

Sorry for being unclear, this is the historical reason why the binutils/gcc
definition of i686 does not include multi-byte NOPs.

While all 32bit x86 hardware is pretty dated in the year 2022, there is still a
surprisingly large number of users of 32bit x86 including like in the case of
this Debian bug on a (likely non-OLPC) Geode.

The Debian i386 port has the toolchain configured for i686, and it is therefore
a problem that due to this gcc bug an autoconf test for -fcf-protection
succeeds.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Just build for those as -march=i586. preventing -fcf-protection with
-march=i686 would be a really bad idea, that would basically prevent all of CET
protection for 32-bit code, i686 is what is used as the supported lowest common
denominator of 32-bit code.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[bunk at stusta dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

--- Comment #4 from Adrian Bunk <bunk at stusta dot de> ---
(In reply to Jakub Jelinek from comment #3)
> Just build for those as -march=i586.

There is no "for those" in Debian.
There is one build of all packages for one i386 Debian release architecture.

Building the Debian i386 architecture with -march=i586 would also remove CMOV
support.

> i686 is what is used as the supported lowest
> common denominator of 32-bit code.

This is not true.

The lowest common denominator of 32-bit x86 code on Linux is -march=i486, since
the 486 is the lowest supported CPU in the kernel.

Distributions usually use various baselines higher than 486 for their 32-bit
x86 ports.
E.g. for distributions dropping support for actual 32-bit hardware (keeping
only multiarch/multilib support), using -march=x86-64 (or whatever higher they
are using for their 64bit x86) might make more sense since it also brings
MMX/SSE/SSE2 which are not in -march=i686 (this also allows using SSE instead
of the x87 FPU with its excess precision oddity).

> preventing -fcf-protection with
> -march=i686 would be a really bad idea, that would basically prevent all of
> CET protection for 32-bit code,

The toolchain emitting instructions not supported by the selected target is
also a really bad idea.

gcc rejecting -fcf-protection for < 686 indicates that this option was not
intended to enable emitting instructions not already supported by the -march
setting.

The proper solution might be a -mmultibyte-nops option?

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc@jp-hosting.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

James Addison <jay+ggcc@jp-hosting.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jay+ggcc@jp-hosting.net

--- Comment #5 from James Addison <jay+ggcc@jp-hosting.net> ---
Adrian wrote:
> To support the Geode in OLPC, the toolchain definition of i686 does include CMOV but it does not include multi-byte NOPs.
...
> Sorry for being unclear, this is the historical reason why the binutils/gcc definition of i686 does not include multi-byte NOPs.

Jakub wrote:
> Just build for those as -march=i586. preventing -fcf-protection with -march=i686 would be a really bad idea, that would basically prevent all of CET protection for 32-bit code, i686 is what is used as the supported lowest common denominator of 32-bit code.

Could the findings indicate that there are two bugs here?

  - The Geode LX target capable of supporting fcf-protection but GCC-11
currently rejects that architecture and flag combination (in the
potentially-buggy code[1] that Adrian refers to)

  - Multi-byte NOPs are emitted for architecture i686 by GCC-11, despite some
CPUs within that architecture lacking[2] support


Also potentially relevant is bug 41989.

[1] -
https://gcc.gnu.org/git/?p=gcc.git;a=blob;f=gcc/config/i386/i386-options.cc;h=805539364108eee07f5bda527acd6f39f3f7bf95;hb=HEAD#l2929

[2] - https://bugzilla.redhat.com/show_bug.cgi?id=579838#c32

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[bunk at stusta dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

--- Comment #6 from Adrian Bunk <bunk at stusta dot de> ---
(In reply to James Addison from comment #5)
> Could the findings indicate that there are two bugs here?
> 
>   - The Geode LX target capable of supporting fcf-protection but GCC-11
> currently rejects that architecture and flag combination

The problem is the opposite.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc@jp-hosting.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

--- Comment #7 from James Addison <jay+ggcc@jp-hosting.net> ---
(In reply to Adrian Bunk from comment #6)
> (In reply to James Addison from comment #5)
> > Could the findings indicate that there are two bugs here?
> > 
> >   - The Geode LX target capable of supporting fcf-protection but GCC-11
> > currently rejects that architecture and flag combination
> 
> The problem is the opposite.

Ok, thank you.

Something that's unclear to me is whether fcf-protection requires NOPL
(multi-byte NOP).  I understand that it requires endbr32.

Was my second statement (re: GCC-11 emitting NOPL for i686) correct?

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc@jp-hosting.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

--- Comment #8 from James Addison <jay+ggcc@jp-hosting.net> ---
(In reply to James Addison from comment #7)
> (In reply to Adrian Bunk from comment #6)
> > (In reply to James Addison from comment #5)
> > > Could the findings indicate that there are two bugs here?
> > > 
> > >   - The Geode LX target capable of supporting fcf-protection but GCC-11
> > > currently rejects that architecture and flag combination
> > 
> > The problem is the opposite.
> 
> Ok, thank you.
> 
> Something that's unclear to me is whether fcf-protection requires NOPL
> (multi-byte NOP).  I understand that it requires endbr32.
> 
> Was my second statement (re: GCC-11 emitting NOPL for i686) correct?

I haven't been able to replicate generation of NOPL instructions using GCC-11
(with GNU binutils); my apologies for the distraction.

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc@jp-hosting.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

James Addison <jay+ggcc@jp-hosting.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jay+ggcc@jp-hosting.net

--- Comment #9 from James Addison <jay+ggcc@jp-hosting.net> ---
(In reply to James Addison from comment #7)
> Something that's unclear to me is whether fcf-protection requires NOPL
> (multi-byte NOP).  I understand that it requires endbr32.

(and now I also understand that the endbr32 instruction is a repurposing of a
previously-existing long-NOP - and that it's required to implement
fcf-protection, aka Intel CET)

[Bug target/104713] gcc does not reject -march=i686 -fcf-protection

[jay+ggcc@jp-hosting.net]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104713

--- Comment #10 from James Addison <jay+ggcc@jp-hosting.net> ---
Hi folks,

Re-stating and confirming the bugreport details here: both gcc-11 (11.3.0) and
gcc-12 (12.2.0) emit bytecode instructions that aren't supported on all
i686-architecture CPUs.

This comment includes a demonstration/repro case to help verify the problem and
potential fixes, along with a suggested remediation approach that is a small
adjustment of Adrian's original suggestion.

As a recap, partly for my own understanding: the 'endbr32' instruction required
to implement Intel Control-flow Enforcement Technology (aka Intel CET) is a
renaming and repurposing of an existing long-NOP (aka NOPL) instruction that
was not documented in the original Pentium Pro specification and therefore is
not supported on all i686-class CPUs.


### Version information

$ gcc-11 --version
gcc-11 (Debian 11.3.0-12) 11.3.0
Copyright (C) 2021 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ gcc-12 --version
gcc-12 (Debian 12.2.0-14) 12.2.0
Copyright (C) 2022 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ objdump --version
GNU objdump (GNU Binutils for Debian) 2.40
Copyright (C) 2023 Free Software Foundation, Inc.
This program is free software; you may redistribute it under the terms of
the GNU General Public License version 3 or (at your option) any later version.
This program has absolutely no warranty.


### Replicating the problem

$ cat repro.c 
int main() {}

$ for prot in full branch return none check; do gcc-11 -m32 -march=i686
-fcf-protection=$prot -c repro.c -o gcc-11-$prot.o; gcc-12 -m32 -march=i686
-fcf-protection=$prot -c repro.c -o gcc-12-$prot.o; done;


### Checking the results

$ for binary in gcc-*.o; do echo $binary; objdump -d $binary | grep -w endbr32
; done;
gcc-11-branch.o
   0:   f3 0f 1e fb             endbr32
gcc-11-check.o
gcc-11-full.o
   0:   f3 0f 1e fb             endbr32
gcc-11-none.o
gcc-11-return.o
gcc-12-branch.o
   0:   f3 0f 1e fb             endbr32
gcc-12-check.o
gcc-12-full.o
   0:   f3 0f 1e fb             endbr32
gcc-12-none.o
gcc-12-return.o


### Remedy

Please could GCC be updated to reject attempts to build binaries for the i686
architecture when fcf-protection is configured to -- or implied to include --
'branch' protection?

Values for the fcf-protection flag were sourced from the GCC documentation at:
https://gcc.gnu.org/onlinedocs/gcc/Instrumentation-Options.html#index-fcf-protection

(as noted: this does duplicate some of the original bugreport's suggestion, but
is intended to be slightly more granular because I believe it's important to
note that not all fcf-protection values are unsupported by the i686
architecture)