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

[Rui Ueyama via Phabricator via llvm-commits]

ruiu added a comment.

In D59780#1452530 <https://reviews.llvm.org/D59780#1452530>, @xiangzhangllvm wrote:

> 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.


I don't think I'm convinced. MaskRay's point is that the tooling's support of CET is buggy and needs changing anyway. Currently it looks like no tool seems to be working correctly. Then, why don't you need to stick with the ABI that is claimed to provide better performance without any evidence? Keeping ABI simple is perhaps much more important than you may be thinking. I really wish you will take it more seriously.

Besides that, I don't think GCC implemented any of the feature of the PLT -- it is only in the BFD linker but not in gold. Also no one is using the feature in the wild because no processors supporting CET is available in the market. Everything seems to be experimental yet at the moment.

> 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