[PATCH] D158574: [AArch64][ELF] Support PAUTH ABI marking

Fri Sep 8 09:48:26 PDT 2023

kovdan01 added a comment.

In D158574#4638533 <https://reviews.llvm.org/D158574#4638533>, @peter.smith wrote:

> The program properties are in the appendix as an alternative. Do we need to implement both for the same platform? If both are supported then we have the problem of what happens when one relocatable object has a notes section and the other a GNU properties section.
>
> The ELF marking in the specification was very much a placeholder in the specification waiting for some implementation experience in prototypes. The notes section was used mostly as GNU properties are a Linux extension, and this may end up being used outside of a GNU platform. I strongly recommend choosing one or the other. Personally I would go with the note section as the properties are listed in an appendix as an alternative.

The implementation proposed in this patch allows only one type of pauth mark at a time: if one of input files has `.note.AARCH64-PAUTH-ABI-tag` section and another one has `GNU_PROPERTY_AARCH64_FEATURE_PAUTH` in `.note.gnu.property`, the linker will emit an error: see lld/test/ELF/aarch64-feature-pauth.s:15:

  error: input files contain both a .note.AARCH64-PAUTH-ABI-tag section and a GNU_PROPERTY_AARCH64_FEATURE_PAUTH feature in a .note.gnu.property section; all the input files must use the same way of specifying AArch64 PAuth compatibility info

I think we can leave this behavior since it's conservative enough, but allows some platforms to use an alternative marking way if they want to.
The compatibility check implemented is pretty generic (treat files as compatible if and only if their PAuth notes are identical), and it can be used as a skeleton if some platform wants something more complex.
Please let me know your thoughts on that - as for now, I don't see major downsides in leaving both ways implemented (if it's explicitly disallowed to mix them), but maybe you see some issues with that.

> Experience from BTI has shown that assembler files, particularly those like crt0.s often creep into projects and are hard to find. Many of these assembler files will have no code pointers in them at all so giving a fatal error may be too harsh.
>
> You may want to follow intel CET, which has a `-z cet-report = [none|warn|error]` for example `-z pauth-report = [none|warn|error]` which controls what happens when there are some objects without the note section.

Thanks! I'll definitely implement that, didn't know that such an option exists. I'll also add the notes manually to assembly files in libunwind though - just in case someone wants to link that with the option set to `error` or using a linker other than lld.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D158574