Re: [PATCH, BFD, LD, AArch64, 0/4] Add support for AArch64 BTI and PAC in the linker

[Sudakshina Das <Sudi.Das@arm.com>]

Hi Nick

On 07/03/2019 12:37, Nick Clifton wrote:
> Hi Sudi,
> 
>    [This is me being kind :-) ...]

Thank you :)
> 
>> 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.

I am CC'ing Peter who would be better able to answer about LLD and GOLD.
> 
> 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).
> 

Yes, I am currently trying to get the glibc patches on the mailing list 
soon but they need some co-ordination with the kernel patches!

> 
>>    - 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 ?

Sorry I should have been clearer with this. The linker does treat it in 
the similar way in collecting the input note section and marking the 
output note section where applicable. The loader however does not do 
much with it.

> 
> 
>> 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 ?

The linker should automatically collect all note sections and mark the 
output with BTI if ALL the inputs have BTI in them. However, in this 
default behavior, if there is any stray objects without the BTI note 
section, the linker will silently remove the BTI note section from the 
output. Both the linker command line options are for users to specify 
that they want the output to be marked with BTI. The difference is that 
--bti will warn about the stray object and --bti-nowarn will not warn.

> 
> [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].

Yes maybe --bti-disable option also makes sense. I will give it some 
more thought on a use case for it.

> 
> 
>> 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.
> 

Unfortunately the format of the document is not in my control but I have 
expressed the need for a downloadable version.

> 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).
> 

Hmm I have not really considered that. I will get back to you soon on this.

> 
> 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 ?
>

We have defined new DT_ tags which can be used as indicators of PLT 
sizes. These tools would need to add support to read these and not use 
hard coded PLT sizes.

> OK, that's it for general comments.  I will reserve patch specific comments
> for each individual patch.
> 
> Cheers
>    Nick
>