[PATCH] D58102: Support X86 Control-flow Enforcement Technology (CET) in LLD

Xiang Zhang via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Thu Feb 14 18:43:48 PST 2019

xiangzhangllvm added a comment.

In D58102#1398886 <https://reviews.llvm.org/D58102#1398886>, @ruiu wrote:

> > 1 Yes, we will disable the feature if not all the input object files contain the .note.gnu.property section, because the CET feature will supervise all the indirect jumps in the program. If one input file do not contain the CET info (flags which is set in  .note.gnu.property section's GNU_PROPERTY_X86_FEATURE_1_AND property ),  it means it can‘t be check by the CET hardware, so we need to disable the CET feature. This is  important to link the non-CET library.
> Looks like the behavior implemented in this patch is this: if all object files are compiled with the CET-enabling compiler option, lld marks the resulting executable as CET-enabled, and if not, mark as otherwise. I think that behavior is error-prone and can be dangerous. Imagine that you already have a program that you use CET. If you make a change to the program and link it against a CET-unaware static library, it would disable CET altogether. I could imagine many different scenarios in which you would accidentally disable CET without knowing.
> So I think a safer approach here is to add a new option to the linker to enable/disable CET. If enabled, lld should verify that all input object files has the .note section and report error if not.

It seems a good idea, please let me think it over for a time, anyway I wish it be an another increment patch if we decide do it.

>> 2 Here we can optimize,  when IBT enabled, we need to insert the ENDBRANCH instructions in the old PLT, at first we don't want to change the PLT size, so we add a SPLT ,the caller first jump to SPLT and then go to PLT. The function of PLT +SPLT = old PLT.
> Can you elaborate a bit as to why you didn't want to change the PLT size? I think PLT should work with a different PLT entry size.
> We actually have an alternative PLT format for a Spectre mitigation, whose PLT entry size is different from the standard one, and that's working fine.

These days I am also re-considering the SPLT way of implementing the IBT of PLT, In fact, at beginning, we thought the size of PLT may be fixed in some SPEC, so we just think that not changing the old PLT's size and use a independent SPLT with the size is a more safe way.
If you think just rewriting the old PLT is better, I'll try to re-implement this part.

  rLLD LLVM Linker



More information about the llvm-commits mailing list