Need dynamic tag to reflect .note.gnu.prop and/or .note.AARCH64-PAUTH-ABI-tag section addresses about abi-aa HOT 3 OPEN

Tagging @smithp35 @kbeyls

It looks like that the method suggested in https://github.com/ARM-software/abi-aa/blob/main/pauthabielf64/pauthabielf64.rst#elf-marking is not quite convenient from dynamic loader perspective as it requires parsing of section table. The latter is not a typical dynamic loader job that operates on segments (and there is no dedicated segment for this section nor entry in dynamic table).

Therefore it seems some alternative way of marking the final ELF binaries should be added that is dynamic-loader friendly. The present way via note sections is more static linker-centric.

from abi-aa.

The existing specification is indeed heavily biased towards static linking. There's a couple of reasons for that one generic and one specific to PAuthABI. In the general case Arm considers ELF marking at the executable/shared-object level as platform specific, i.e. Linux, Android, *BSD or a proprietary OS could define their own individual marking scheme. The specific one is that the initial driver behind the PAuthABI was for statically linked code only so the output in the executable didn't matter that much.

The intention behind the notes section was something simple for the Alpha specification using existing ELF extensions (SHT_NOTES) that would be easy to experiment with. When sufficient experience had been gained with the Alpha a more serious attempt could be made at a marking scheme if there was hope of an OS like Linux/Android wanting support. For proprietary platforms the notes sections could easily be translated into whatever platform specific format would work with the dynamic loader for the platform.

It is definitely possible that we could write a more dynamic linker friendly output for the specification. However I need to be careful with what I can promise about its stability. The specification is in Alpha and if something like PAuthABI was picked up by a linux distro then we would need to negotiate with the kernel, glibc, bionic over what the marking scheme is, so it could change in the future.

from abi-aa.

Linkers create PT_NOTE program headers from SHT_NOTE sections. There should not be too much concern as in the absence of a dedicated PT_ program header, rtld can process PT_NOTE.

Actually, it's a common practice for rtld to process PT_NOTE.
E.g. glibc elf/dl-load.c processes both PT_NOTE and PT_GNU_PROPERTY.
The aarch64 port handles PT_GNU_PROPERTY and ignores PT_NOTE while the x86 port handles PT_NOTE and ignores PT_GNU_PROPERTY.

from abi-aa.