This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker
- From: Nick Clifton <nickc at redhat dot com>
- To: Sudakshina Das <Sudi dot Das at arm dot com>, "binutils at sourceware dot org" <binutils at sourceware dot org>
- Cc: nd <nd at arm dot com>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Ramana Radhakrishnan <Ramana dot Radhakrishnan at arm dot com>
- Date: Thu, 7 Mar 2019 12:37:03 +0000
- Subject: Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker
- References: <08762e41-1e80-a504-d840-f8715ea59a50@arm.com>
Hi Sudi,
[This is me being kind :-) ...]
> We introduce a new set of command line options for the linker in order
> to support the correct PLTs
Are you also planning on creating patches for GOLD and LLD to support
these features ? If so, it would probably be best to submit them at
the same time as the BFD linker patches.
Presumably there will also need to be a patch to the loader. Has this
patch been prepared ? (Obviously we cannot approve such a patch here,
but it would be good if this patch series included a link to the glibc
patch, and vice versa).
> - GNU_PROPERTY_AARCH64_FEATURE_1_PAC (We have only reserved this bit
> for now.)
Why is this bit only reserved at the moment ? Shouldn't the linker
patches be treating this bit in a similar way to the GNU_PROPERTY_AARCH64_FEATRUE_1_BTI
bit ?
> 3)--bti-nowarn - Same as above but does not emit any warnings.
I am not clear about the purpose/need for this option. According to this:
> 2) For BTI, the linker must also check for the
> GNU_PROPERTY_AARCH64_FEATURE_1_BTI in its input. If all inputs have
> GNU_PROPERTY_AARCH64_FEATURE_1_BTI, the final output will also be marked
> as such. The PLT should also be protected with a BTI PLT in this case.
> Thus even if there is no linker option to use BTI PLT, the linker
> should be able to use them depending on the NOTE section. The user can
> use the linker option --bti, to make sure that their intention of having
> all input objects (and hence the output) marked with BTI is not
> disrupted by any stray objects as this option will warn about it.
The linker will automatically set the BTI tag if all of the inputs have
the BTI note, and, by default, will not warn if one or more of the inputs
do not have the note. So what does the --bti-nowarn option do ?
[As an aside, do you think that there might be a need for a --bti-disable
option, which would stop the setting of the BTI tag, even if all of the
input objects have the BTI note ? I am not sure myself, but I suppose in
theory there might be some reason to want this].
> Details of these can be found in the new AArch64 ELF documentation:
> https://developer.arm.com/docs/ihi0056/latest/elf-for-the-arm-64-bit-architecture-aarch64-abi-2018q4
It would be nice if this document was available as a PDF or something
similar, so that it could be downloaded and used offline.
The document does not appear to specify what the loader should do if
there is more than one GNU_PROPERTY_AARCh64_FEATURE_1_AND note in an
executable. (Which would be there if the executable had been linked
by a linker that does not know how to merge multiple GNU_PROPERTY notes).
Have you considered how these new PLTs will affect other tools that
inspect them ? For example ltrace or glibc's la_pltenter() and la_pltexit()
functions ?
OK, that's it for general comments. I will reserve patch specific comments
for each individual patch.
Cheers
Nick