Hi Dave, On Thu, Feb 11, 2021 at 09:06:12AM -0800, Dave Hansen wrote: > I noticed there are some ELF bits for ARM's BTI feature: > > GNU_PROPERTY_AARCH64_FEATURE_1_BTI > > > https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/include/uapi/linux/elf.h#n453 > > There's been talk of needing a similar set of bits on x86 for tagged > pointers (LAM). Do you have any plans to do something similar (ELF > property bits) for any of the pointer tagging features? Not at the moment but see below. Tagged addresses were supported on arm64 from day 0, though they were not used much (I think some JITs attempted to encode pointer types in the top byte). Until recently, we haven't allowed such tagged pointers as syscall arguments. The need for wider use of tagged pointers and the syscall ABI relaxation came from the ASan/HWASan work on LLVM and the subsequent Memory Tagging Extensions (MTE). With the latter, the user code doesn't need to be recompiled, only the right heap allocator to be loaded. So you could do an LD_PRELOAD to override malloc/free to return tagged pointers (I did this in the past to run a standard Debian + LTP testing). So we decided that it's easier for the C library to invoke a prctl() if needed rather than having some ELF property. MTE also requires additional control (like synchronous/asynchronous tag checking) which we added to the same prctl() to be done in a single call. That's, again, the decision of the C library together with using mmap(PROT_MTE) for the heap regions. That said, since HWASan requires code instrumentation, it would have been nice if some GNU property was present as not to mix&match such objects. I guess since it's mostly a debug feature, people didn't bother but it would probably fall apart if you mix it with MTE. With MTE, at some point we may deploy stack tagging which requires instrumentation of the function prologue/epilogue and mapping the stack with PROT_MTE. That's not widely used at the moment since such instructions are undef on previous CPU implementations. We may end up with an ELF annotation to distinguish such objects but I think that's still up for discussion. The reason for the BTI property was static binaries that needed PROT_BTI on their exec sections to be set by the kernel. MTE did not have such need (the C library would pass PROT_MTE explicitly on heap allocations) and neither did the top-byte-ignore feature. For the LAM feature, if the code is identical (e.g. it's the C library deciding whether malloc() returns tagged pointers), I don't see much use for an ELF annotation. However, if the plan is for something similar to HWASan with different code generation, it may be safer to just add a GNU note. -- Catalin
