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

Fri Mar 1 22:08:23 PST 2019

MaskRay added a comment.

> // Now the IBT can't work with retpolineplt feature, becasue they may conflict
>  // in changing the PLT. So we disable the IBT when the IFUNC enabled.

According to Retpoline-A-Branch-Target-Injection-Mitigation.pdf <https://software.intel.com/security-software-guidance/api-app/sites/default/files/Retpoline-A-Branch-Target-Injection-Mitigation.pdf> Section 4.3

> To avoid this conflict, future Intel processors implementing CET will also contain hardware mitigations for branch target injection (Spectre variant 2) (enhanced IBRS), that obviate the need for retpoline.

I hope this will be true (CET and enhanced IBRS) and retpolineplt will no longer be needed. If that is the case, you may delete `Config->ZRetpolineplt` checks from CET handling code and add an incompatibility error in `ELF/Driver.cpp:checkOptions`:

  if (Config->IntelCET && Config->ZRetpolineplt)
    error("--intel-cet may not be used with -z retpolineplt");

> Given that we will have at least two targets implementing a similar mechanism but with target specific details then we'll either need to make it my responsibility to generalise the .note.gnu.property implementation so that it can support both AArch64 and X86, or we make it generic from the start. The main difference for AArch64 is that there are two independent feature bits to track.
> 
> Soon happened to be a few hours ago: https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2018q4 search for BTI and PAC

@peter.smith Looking forward to a generic `.note.gnu.property` mechanism! Hope the ABI will soon get a PDF version (for now the link is nearly unsearchable. The avaiable PDF is pretty old (of version May 22, 2013)).

> When creating an input file, create a .note section with appropriate contents when --intel-cet was given.

I believe executable stack has been considered bad since 1990s. lld is new(fortunate) enough to make an elegant choice: simply default to noexecstack and not to care about `--warn-execstack` and the tricky `is_default_stack_executable()` `warn_execstack()` states. For CET we do need to consider transition plans, which may make the logic complex (I am also not happy with that).

@ruiu Have you considered a `--warn-intel-cet` (or `--error-intel-cet`, `--intel-cet-handling=error`, `-z intel-shstk` `--intel-cet=ibt,shstk`)?

- AND-feature bits (`GNU_PROPERTY_AARCH64_FEATURE_1_AND` `GNU_PROPERTY_X86_FEATURE_1_AND`) in `.note.gnu.property` will always be handled and emitted into linked executable/DSO
- If the option is seen but the secure bit of the result AND-feature is not set, report a warning/error.

Users should not believe the executable/DSO is CET protected unless the option is used in linking.

Repository:
  rLLD LLVM Linker

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

https://reviews.llvm.org/D58102