[Bug target/98997] New: Linking mismatched -fcf-protection objects generates incorrect code

[Bug target/98997] New: Linking mismatched -fcf-protection objects generates incorrect code

[luto at kernel dot org]

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

            Bug ID: 98997
           Summary: Linking mismatched -fcf-protection objects generates
                    incorrect code
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: luto at kernel dot org
  Target Milestone: ---

$ gcc --version
gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)
Copyright (C) 2020 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.

$ cat cet1.c
#include <setjmp.h>

void test(jmp_buf buf)
{
        __builtin_longjmp(buf, 1);
}
$ cat cet2.c
#include <setjmp.h>

void test(jmp_buf buf);

int main()
{
        jmp_buf buf;
        if (__builtin_setjmp(buf) == 0)
                test(buf);
        return 0;
}
$ gcc -c -O2 cet1.c -fcf-protection=full
$ gcc -c -O2 cet2.c
$ gcc -o cet -O2 cet1.o cet2.o
$ ./cet
Illegal instruction (core dumped)

Presumably the magic CET fixup in the builtin setjmp/longjmp requires that
matching code is generated for both.  I'm testing on a non-CET system.

I haven't even tried to figure out if anything sensible happens to the CET GNU
property, but I think the current GCC behavior is impolite at best.  I think
GCC should do one of a few things:

1. Generate working code.

2. Fail to link.

3. At least document this pitfall very clearly.

I really hope this doesn't affect shared objects.

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|unknown                     |10.2.1
             Target|                            |x86_64-*-* i?86-*-*

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
__builtin{setjmp,longjmp} are internal to GCC (for SJLJ EH), they do _not_
map to setjmp/longjmp in glibc.  Just in case this matters here.

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2021-02-08
             Status|UNCONFIRMED                 |NEW

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
A patch is posted at

https://gcc.gnu.org/pipermail/gcc-patches/2021-February/564972.html

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[luto at kernel dot org]

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

--- Comment #3 from Andy Lutomirski <luto at kernel dot org> ---
What is -fcf-protection=stack actually supposed to do as compared to
-fcf-protection=none?  Is it valid to run code compiled with
-fcf-protection=none with SHSTK enabled?  If so, then I wonder why
-fcf-protection=stack exists at all.  If not, then I'm wondering why your patch
seems to be effectively hardcoding "stack" mode for SJLJ?

You could probably fix this bug differently by changing __builtin_setjmp() to
store 0 for SSP in "none" mode.  Then at least -fcf-protection=none wouldn't
emit CET code.

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[luto at kernel dot org]

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

--- Comment #4 from Andy Lutomirski <luto at kernel dot org> ---
I should add: on brief inspection, that patch looks like an ABI break for
-fcf-protection=none

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[hjl.tools at gmail dot com]

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

--- Comment #5 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Andy Lutomirski from comment #3)
> What is -fcf-protection=stack actually supposed to do as compared to

It is -fcf-protection=return.

> -fcf-protection=none?  Is it valid to run code compiled with
> -fcf-protection=none with SHSTK enabled?  If so, then I wonder why

No.  The binary will crash.

> -fcf-protection=stack exists at all.  If not, then I'm wondering why your
> patch seems to be effectively hardcoding "stack" mode for SJLJ?
> 

Correct.

[Bug target/98997] Linking mismatched -fcf-protection objects generates incorrect code

[hjl.tools at gmail dot com]

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

--- Comment #6 from H.J. Lu <hjl.tools at gmail dot com> ---
(In reply to Andy Lutomirski from comment #4)
> I should add: on brief inspection, that patch looks like an ABI break for
> -fcf-protection=none

True if __builtin_longjmp and __builtin_setjmp are compiled by different
compilers.