[PATCH] D119384: [MTE] [lld] Add --memtag-* options to synthetise ELF notes.

Tue Mar 15 10:50:58 PDT 2022

hctim added a comment.

In D119384#3374699 <https://reviews.llvm.org/D119384#3374699>, @MaskRay wrote:

> I know little about MTE. Do you have a companion Bionic change? If yes, seems useful to share the link here so that people will see the big picture.

The memtag code has existed on Android since Android 11 (2021): https://cs.android.com/android/platform/superproject/+/master:bionic/libc/bionic/libc_init_static.cpp;drc=ba842429a777575fb683e21c31c5d962305b93fd;l=207

Unfortunately, this makes the implementation, for Android, inflexible, as we'd like binaries built with the new toolchain to work on older versions..

In D119384#3374699 <https://reviews.llvm.org/D119384#3374699>, @MaskRay wrote:

> Currently `--memtag-*` seems Android specific while Android specific options should have `android` in the names.
> If `--memtag-*` may be used by regular AArch64 programs, then using `--memtag-*` seems fine.

In D119384#3380538 <https://reviews.llvm.org/D119384#3380538>, @MaskRay wrote:

> If you need something soon for experiments, the Android ABI may need to diverge from the generic AArch64 ABI.
> (Something similar to `--pack-dyn-relocs=android+relr`.)
> I think Android needs to use `--android-memtag-*` instead of the generic option names `--memtag-*`.
> We can consider the options experimental. When AArch64 ABI gets a proposal and Android is happy to switch to the standard, we should remove the experimental options.

I don't see renaming the current linker options to `--android-memtag*` as a problem, and seems to remove the concerns of "this ABI is nonstandard and potentially android-specific." Especially given that the name of the note is `"Android"`, which can't be changed due to the aforementioned need for backwards-compatibility.

> There is also a way not adding linker options.
> You may just synthesize an object file according to sync/async and stack/heap:
>
>   .section .note.gnu.property, "a", %note
>   .p2align 3
>   ...
>
> and let clang Driver link it into the output.
> This may be a bit inconvenient as it needs object files for all combinations, but don't need to let linker commit to an unstable interface.

This is what is currently done on Android, but we'd like to move the behaviour to the toolchain as it's necessary to implement MTE stack, as it need collaboration from the loader.

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

> Some initial thoughts.
>
> - If this is likely to be rolled out to other platforms such as Linux/BSD etc. It would be useful to have something common written up in the ABI. As MaskRay suggests the best way forward would be to raise an issue or a pull request https://github.com/ARM-software/abi-aa . You are of course welcome to implement an Android specific platform ABI, but it would be good to a similar one across multiple platforms if possible.
> - For BTI, for better or worse, we chose to  https://github.com/ARM-software/abi-aa/blob/main/aaelf64/aaelf64.rst#62program-property as this mechanism was going to be needed for Intel platforms. Ideally this would be documented in the SysVABI doc, but that didn't exist at the time the property was created.

`GNU_PROPERTY_AARCH64_FEATURE_1_AND` seems like a reasonable place to implement these features in a generic standpoint, but we still need the android-specific behaviour for backwards compatibility.

> - Do you need per-object marking that a linker will aggregate? For example do you enable when at least one object needs MTE, or do you need all objects to be compatible with MTE? A per object marking that can be overridden at link time will give you a chance to diagnose objects that may not have the MTE support. It can help to have an assembler option to fabricate the note if objects are used.

The ELF note is coupled with the executable, not the DSOs, and thus the executable decides what MTE options are enabled. In future, there will be a per-DSO progbits section for MTE global descriptors, but these progbits sections will be ignored if the main executable doesn't include the MTE ELF note. And, of course, MTE stack is enabled on a per-CU level.

> - A colleague mentioned that the choice of command line options were quite generic. If they are aarch64 and Android specific they probably ought to be behind -z and perhaps with AArch64 and Android in the name.

As above, agreed regarding the `*android*` naming of the notes. I don't think they need to be platform-specific, as I'd expect a generic `--android-memtag*` to be able to correctly synthesize notes for AArch64 and any future platforms that support memory tagging.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D119384