This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/2] aarch64: Enable pointer auth in PLT
On 24/06/2019 18:50, Szabolcs Nagy wrote:
> On 24/06/2019 17:28, Florian Weimer wrote:
>> * Szabolcs Nagy:
>>
>>> there is no easy way to mark binaries such that
>>> old loader rejects them if it does not understand
>>> the marking.
>>
>> There are symbol versions, new relocation types, and EI_ABIVERSION.
>> For the latter, see libc-abis.
>
> bumping EI_ABIVERSION may work for pac-plt, i'll look
> into it (that will have to be documented in the elf abi).
this does not seem to work because of the kernel
loaded executable issue.
>
> an alternative is to leave the elf abi as is and solve this
> in the bfd linker by -z pac-plt implying -u __pac_plt_supported
> and adding __pac_plt_supported symbol to glibc.
> (i.e. only solve this in the tooling, the magic symbol
> ref is not required by the elf abi, just a safety net
> provided by the binutils implementation, a huge hack,
> but in practice it should be enough)
i could not get this to work so i will not aim
for glibc 2.30, i will try to get something done
in binutils before the release with -z pac-plt.
>
> i think a new dynamic reloc requires too many changes
> with non-trivial consequences.
>
>>> the kernel api won't change since the architecture
>>> does not make it easy to disable pauth per process.
>>
>> That's rather … strange. Do you know why things have to be this way?
>> Since these instructions live in the NOP space, you end up with binaries
>> that could not have been tested against hardware support for this
>> feature for a long time. And without a per-process knob, you don't have
>> a way to get this binaries running if a need for that arises.
>
> i don't know the details, but the knob is in the sctlr_el1
> system register that affects both EL1 and EL0 (kernel and
> userspace) so if the kernel uses pauth then it cant just
> disable it per process and there may be other reasons it
> cannot be context switched efficiently. (in a kvm virtual
> machine presumably you can turn it off)
>