[PATCH] D128958: Add assembler plumbing for sanitize_memtag

Mitch Phillips via Phabricator via llvm-commits llvm-commits at lists.llvm.org
Tue Aug 9 11:34:25 PDT 2022


hctim added a comment.

In D128958#3710572 <https://reviews.llvm.org/D128958#3710572>, @enh wrote:

> In D128958#3653055 <https://reviews.llvm.org/D128958#3653055>, @hctim wrote:
>
>> 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).
>
> fwiw, i don't think this case is as bad as compressed relocations because there's no NDK MTE ABI anyway, so this would only affect platform code. it would be annoying for SoC vendors/OEMs needing to rebuild prebuilts (and we'd need the backwards compatibility for 3+ years so that new system image + old vendor image still worked), but at least this wouldn't leak to app developers.
>
> that said, it would still be ideal to get to an official ARM ABI before Android U is finalized early next year --- that would make it more likely we can avoid any disruption.

I think it could leak to very progressive app developers - globals are tagged on a per-DSO basis and (at least now) `dlopen` doesn't discriminate between platform DSOs and app DSOs.

We could change that if we didn't want to have ABI problems, but if we ship MTE globals in an apex, we need the backwards compatibility anyway.

In the MemtagABI doc I'm drafting it also has dynamic table entries so that we can move off of the elf note for specifying heap/stack/etc., so that'd need to stick around for a few generations as well.

I think we'll just end up supporting both an old and a new for a few generations anyway.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D128958



More information about the llvm-commits mailing list