[PATCH] D59780: Support Intel Control-flow Enforcement Technology

[Xiang Zhang via Phabricator via llvm-commits]

xiangzhangllvm added a comment.

Hi MaskRay, I tested your idea by changing the patch:

  diff --git a/ELF/Arch/X86_64.cpp b/ELF/Arch/X86_64.cpp
  index 7d7cc00..14fb6b2 100644
  --- a/ELF/Arch/X86_64.cpp
  +++ b/ELF/Arch/X86_64.cpp
  @@ -553,11 +553,11 @@ void IntelCET::writePlt(uint8_t *Buf, uint64_t GotPltEntryAddr,
                           unsigned RelOff) const {
     const uint8_t Inst[] = {
         0xf3, 0x0f, 0x1e, 0xfa,       // endbr64
  -      0xff, 0x25, 0,    0,    0, 0, // jmpq *got(%rip)
  -      0x66, 0x0f, 0x1f, 0x44, 0, 0, // nop
  +      0xf2, 0xff, 0x25, 0,    0,    0, 0, // jmpq *got(%rip)
  +      0x0f, 0x1f, 0x44, 0, 0, // nop
     };
     memcpy(Buf, Inst, sizeof(Inst));
  -  write32le(Buf + 6, GotPltEntryAddr - PltEntryAddr - 10);
  +  write32le(Buf + 7, GotPltEntryAddr - PltEntryAddr - 11);
   }

After that, GNU objdump can symbolize .plt.sec, it is really the BND prefix factor.

  [xiangzh1 at shliclel100 /export/users.shared/xiangzh1/LLVM_ORG/test]$ld.lld -e func1 t.o t1.so -o tout-new
  [xiangzh1 at shliclel100 /export/users.shared/xiangzh1/LLVM_ORG/test]$objdump -d tout-new
  
  tout-new:     file format elf64-x86-64
  
  
  Disassembly of section .text:
  
  0000000000201000 <func1>:
    201000:       e8 3b 00 00 00          callq  201040 <func2 at plt>
    201005:       e8 46 00 00 00          callq  201050 <func3 at plt>
    20100a:       c3                      retq
  
  Disassembly of section .plt:
  
  0000000000201010 <.plt>:
    201010:       ff 35 f2 1f 00 00       pushq  0x1ff2(%rip)        # 203008 <_DYNAMIC+0x1008>
    201016:       ff 25 f4 1f 00 00       jmpq   *0x1ff4(%rip)        # 203010 <_DYNAMIC+0x1010>
    20101c:       0f 1f 40 00             nopl   0x0(%rax)
    201020:       f3 0f 1e fa             endbr64
    201024:       68 00 00 00 00          pushq  $0x0
    201029:       e9 e2 ff ff ff          jmpq   201010 <func1+0x10>
    20102e:       66 90                   xchg   %ax,%ax
    201030:       f3 0f 1e fa             endbr64
    201034:       68 01 00 00 00          pushq  $0x1
    201039:       e9 d2 ff ff ff          jmpq   201010 <func1+0x10>
    20103e:       66 90                   xchg   %ax,%ax
  
  Disassembly of section .plt.sec:
  
  0000000000201040 <func2 at plt>:
    201040:       f3 0f 1e fa             endbr64
    201044:       f2 ff 25 cd 1f 00 00    bnd jmpq *0x1fcd(%rip)        # 203018 <func2>
    20104b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
  
  0000000000201050 <func3 at plt>:
    201050:       f3 0f 1e fa             endbr64
    201054:       f2 ff 25 c5 1f 00 00    bnd jmpq *0x1fc5(%rip)        # 203020 <func3>
    20105b:       0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)

But I think this is not the good reason to change the ABI, it is better to change the objdump tool's code to fit the new plt.
GCC have implemented this ABI for one year, It will be very hard to push the changing work.

We never considered optimizing the PLT entry size, because we can not make sure how the developers to "deal with" the old 16-bytes plt in their old programs.
That is also one of the reasons why GCC (H.J.) split the plt to 2 16-bytes plts at first.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D59780/new/

https://reviews.llvm.org/D59780