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

Wed Oct 16 02:43:40 PDT 2019

MaskRay accepted this revision.
MaskRay added a comment.

In D59780#1709046 <https://reviews.llvm.org/D59780#1709046>, @annita.zhang wrote:

> Hi,
>
> I added a comment to x86-64 ABI google group link <https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/sQcX3__r4c0>. I also posted it below.
>
> This CET ABI issue was raised during glibc discussion in GCC Cauldron. The conclusion was CET ABI wouldn’t be changed. It’s not because it’s a better option, but because it’s been finalized for 2 years (in 2017). And the implementation has been included in Linux distributions already. There's no obvious reason to change it w/o a pretty better solution.
>
> On the other hand, Intel wants to support it in LLVM lld anyway. But we don’t want to force lld developers to do what they don’t want. So now the ball is at lld side. If lld would like to follow the CET ABI, we’re willing to submit the corresponding lld patches. If not, we will submit the lld patches supporting 32-byte PLTs. The disadvantage of the latter is ABI is incompatible between GCC and LLVM for CET. It may cause potential issues in some tools which has dependence on PLT size and layout. But we don’t have known samples yet. From our estimation, the risk may be low.
>
> I’m looking forward to hearing your opinions and moving it forward.
>
> Thanks,
> Annita

I actually made a similar proposal https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/Z6GqQDy_NaI in April but it did not spur discussions. 
Ali Bahrami and Michael Matz were active in generic-abi discussions. I am really glad they commented on https://groups.google.com/forum/?hl=en#!topic/x86-64-abi/sQcX3__r4c0 My summary is that many people think .plt.sec is overengineered. Carlos's stance is fairly obvious from the discussion. It is just too late to fix anything. (Gossip is that it is probably only Carlos himself cares about the auditing feature in glibc... As people have pointed out, very few libc implementations (just glibc and Solaris libc) support auditing so this does not surprise me at all -;))

In the Cauldron, GCC/LLVM Collaboration BoF was a topic. The PLT scheme argument reflects a bigger problem that some collaboration does not work well. I will give an example about the latest binutils 2.33.1 release. I caught the objcopy --set-section-alignment problem in the last minute (https://sourceware.org/ml/binutils/2019-10/msg00008.html). I would regret if the problematic objcopy patch slipped through and GNU developers were reluctant to change it - which would mean llvm-objcopy would not have an ideal solution. Recently in another case, I caught a problem related to .ctf but I guess GNU maintainers will not care <https://sourceware.org/ml/binutils/2019-10/msg00062.html> my opinion. I'll stop as it may be too off-topic now.

For my own notes, I should follow binutils, libc-alpha, and x86-64-abi discussions more closely.

I accepted this patch. I am still sad about the .plt.sec scheme but am not opposed to this patch. It is up to @ruiu to rebase the patch and commit it.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59780