[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

[Momchil Velikov via Phabricator via llvm-commits]

chill added a comment.

I don't think this behaviour is correct with regard to the specification (AAELF64 2020Q2):

> Static linkers processing ELF relocatable objects must set the feature bit in the output object or image
>  only if all the input objects have the corresponding feature bit set.



> GNU_PROPERTY_AARCH64_FEATURE_1_BTI This indicates that all executable sections are compatible with
>  Branch Target Identification mechanism. An executable or shared object with this bit set is required to
>  generate Custom PLTs (page 35) with BTI instruction.
> 
> GNU_PROPERTY_AARCH64_FEATURE_1_PAC This indicates that all executable sections have Return Address
>  Signing enabled. An executable or shared object with this bit set can generate Custom PLTs (page 35)
>  with a PAC instruction.

Compatibility of executable sections ultimately depends on each individual function, therefore
it cannot be inferred from command-line options alone (transitively from module flags), which
merely set a default that can be overridden by function attributes.

If any function has the attribute "sign-return-address", then the output note
section should have PAC bit set. The return address signing is completely local
to the function, and functions with or without return address signing can be
freely mixed with each other.

Likewise, if any function has the attribute "branch-target-enforcement", then
the output note section should have the BTI flag set. Even though code compiled
with BTI is not necessarily compatible with non-BTI code:

- the only way to get BTI code is by explicit use of `-mbranch-protection=...` command-line option, or the corresponding attribute, which we should consider a clear indication about the user's intent to use BTI.
- the only way to get a mix of present/non-present "branch-target-enforcement" attributes is by the explicit use of the `__attribute__((target("branch-protection=..."))`, in which case we should assume the user knows what they are doing.

What do to if there are no functions in the compile unit?

Technically, objects produced from such a unit are fully compatible with both PAC and BTI, which
means both flags should be set. But looking at the (non-existent) function attributes alone does
not allow us to unambiguously derive a user's intent to use PAC/BTI. In this case, I would suggest
setting the ELF note flags, according to the LLVM IR module flags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80791