[PATCH] D128958: Add assembler plumbing for sanitize_memtag

Thu Jul 14 13:24:21 PDT 2022

hctim added a comment.

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

> Purely on the ABI front, I've got some questions and suggestions.
>
> As a general open question, what are your ABI plans? Is it to create an Android specific ABI for .memtag, which presumably will need to be maintained for some period of time? I assume that if there is an alternative Linux ABI defined, presumably in the AArch64 ABI https://github.com/ARM-software/abi-aa then you'll consider adopting that?

I think the AArch64 ABI is a reasonable place for this - however my main concern is that I have zero experience with non-Android loaders, and no experience with other linkers outside of lld. As such, it's hard to estimate the "unknown unknowns" of those areas.

There is also a separate piece that is part of this work that belongs in the linker. In summary, it's a special section with a series of ULEB-encoded pairs of `{offset, size}` descriptors (one for each global variable that wants to be tagged).

I'll draft up an MTE AArch64 ABI extension over there, but will probably need some hand holding :).

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use `aarch64` reservations, or `Android` reservations? I would hope that we can avoid a RELR-style launch where Android supports some scheme for a few generations, then the generic ABI variant comes about, and then Android has to support both (and app developers have to use the old one for backwards compatibility, but that's not always obvious).

> As an aside the ABI is open for contributions https://github.com/ARM-software/abi-aa/blob/main/CONTRIBUTING.md if there is an effort to get a memtag ABI defined (not aware of one internally) we'd like to work with everyone to write something up. The PAuthABI (https://discourse.llvm.org/t/llvm-pointer-authentication-sync-ups/62661/5) is an example of that. We have an ELF extension https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst that has some additional relocations and dynamic relocations reserved.

Fortunately, the current design fits without having to create new relocations (we did have a previous RFC that required new relocations for optimisation, but that's not our focus right now). We do re-use existing relocation types in a new novel way (like the `R_NONE` in a special section in this patch, or applications of memory tags in `R_RELATIVE` and other dynamic relocations).

> For Arm/AArch64 specific sections, although I can't find it written down as "reserved" we try and follow a naming convention for Arm/AArch64 specific sections such as `.ARM.attributes` . My expectation is that anything that we define that is `SHT_PROGBITS` that is specific to Arm/AArch64 will have a `.ARM.` or `.AArch64.` prefix. If your section name is specific to Android, but could be supported on other architectures at some future point, could you use something like `.Android.memtag`?

For now though, to allow experimentation and further development, it would be great to temporarily reserve some section identifiers and semantics. Do you think we should use `aarch64` reservations, or `Android` reservations?

> For the `.memtag` directive there could be a parameter, potentially optional that changed its behaviour. For example `.memtag huge, android` `.memtag huge, arm`. It wouldn't be the end of the world if there had to be a second directive with a different name, although that would be potentially confusing. There doesn't seem to be a naming convention for directives in GNU assembler like there would be section names.

Isn't the compile target enough for this? For example, we might also want to (on some Android NDK version gate) do something different, which would be implied by the `##` part of the `aarch64-linux-android##` target. I also believe that the name here is generic enough to be used by other architectures (x86, etc.) in future.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128958