[Bug target/96350] New: [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[Bug target/96350] New: [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[crazylht at gmail dot com]

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

            Bug ID: 96350
           Summary: [cet] For ENDBR immediate, the binary would include a
                    gadget that starts with a fake ENDBR64 opcode.
           Product: gcc
           Version: 11.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: target
          Assignee: unassigned at gcc dot gnu.org
          Reporter: crazylht at gmail dot com
                CC: hjl.tools at gmail dot com
  Target Milestone: ---
            Target: i386, x86-64

ENDBR32 and ENDBR64 have specific opcodes:
-       ENDBR32: F3 0F 1E FB
-       ENDBR64: F3 0F 1E FA

And we want that attackers won’t find unintended ENDBR32/64 opcode matches in
the binary

Here’s an example:

If the compiler had to generate asm for the following code:
a = 0xF30F1EFA

it could, for example, generate:
mov 0xF30F1EFA, dword ptr[a]

In such a case, the binary would include a gadget that starts with a fake
ENDBR64 opcode.

Therefore, the requirement from the compilers is to split such generation into
multiple operations, such that the explicit immediate never shows in the binary

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[hjl.tools at gmail dot com]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|                            |2020-07-28
     Ever confirmed|0                           |1
   Target Milestone|---                         |11.0
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> ---
[hjl@gnu-snb-1 tmp]$ cat foo.c
int
foo (void)
{
  return 0xfa1e0ff3;
}
[hjl@gnu-snb-1 tmp]$ gcc -c -O2 foo.c
[hjl@gnu-snb-1 tmp]$ objdump -dw foo.o

foo.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   b8 f3 0f 1e fa          mov    $0xfa1e0ff3,%eax
   5:   c3                      ret    
[hjl@gnu-snb-1 tmp]$ objdump -dw  --start-address=1 foo.o

foo.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000001 <foo+0x1>:
   1:   f3 0f 1e fa             endbr64 
   5:   c3                      ret    
[hjl@gnu-snb-1 tmp]$

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> ---
We can force 0xfa1e0ff3 into memory with

[hjl@gnu-snb-1 tmp]$ cat bar.s
        .text
        .p2align 4
        .globl  foo
        .type   foo, @function
foo:
        movl    .LC0(%rip), %eax
        ret
        .section .rodata.cst4,"aM",@progbits,4
        .align 4
.LC0:
        .long  0xfa1e0ff3
        .section        .note.GNU-stack,"",@progbits
[hjl@gnu-snb-1 tmp]$ gcc -c bar.s
[hjl@gnu-snb-1 tmp]$ objdump -dwr bar.o

bar.o:     file format elf64-x86-64


Disassembly of section .text:

0000000000000000 <foo>:
   0:   8b 05 00 00 00 00       mov    0x0(%rip),%eax        # 6 <foo+0x6>     
2: R_X86_64_PC32        .LC0-0x4
   6:   c3                      ret    
[hjl@gnu-snb-1 tmp]$

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[rguenth at gcc dot gnu.org]

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

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The endbr are way too short to make this practical - ISTR I raised this exact
issue at a presentation about CET ... CET simply makes the gadget finding less
likely to succeed.

There's always the possibility that text relocations end up making ENDBR{32,64}
appear.

Eventually the assembler (and ld.so?) can receive a hardening flag to scan for
those byte sequences.

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[hjl.tools at gmail dot com]

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

--- Comment #4 from H.J. Lu <hjl.tools at gmail dot com> ---
Created attachment 48944
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=48944&action=edit
An experimental patch

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[cvs-commit at gcc dot gnu.org]

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

--- Comment #5 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by hongtao Liu <liuhongt@gcc.gnu.org>:

https://gcc.gnu.org/g:9a5381f749ee2cef51af67895de182113e45f642

commit r11-2716-g9a5381f749ee2cef51af67895de182113e45f642
Author: liuhongt <hongtao.liu@intel.com>
Date:   Tue Aug 4 10:00:13 2020 +0800

    Force ENDBR immediate into memory.

    gcc/
            PR target/96350
            * config/i386/i386.c (ix86_legitimate_constant_p): Return
            false for ENDBR immediate.
            (ix86_legitimate_address_p): Ditto.
            * config/i386/predicates.md
            (x86_64_immediate_operand): Exclude ENDBR immediate.
            (x86_64_zext_immediate_operand): Ditto.
            (x86_64_dwzext_immediate_operand): Ditto.
            (ix86_endbr_immediate_operand): New predicate.

    gcc/testsuite
            * gcc.target/i386/endbr_immediate.c: New test.

[Bug target/96350] [cet] For ENDBR immediate, the binary would include a gadget that starts with a fake ENDBR64 opcode.

[crazylht at gmail dot com]

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

Hongtao.liu <crazylht at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|---                         |FIXED
             Status|NEW                         |RESOLVED

--- Comment #6 from Hongtao.liu <crazylht at gmail dot com> ---
Fixed in GCC11.