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

[Sudakshina Das <Sudi dot Das at arm dot com>]

Hi

On 08/03/2019 12:44, Ramana Radhakrishnan wrote:
> On 08/03/2019 12:32, Nick Clifton wrote:
>> Hi Guys,
>>
>>>> Given this conversation, maybe renaming --bti to --force-bti would
>>>> express the intention clearer ?
>>
>> Yes - I rather like that idea.
>>
>>> Indeed warnings can be ignored in most cases, particularly when there
>>> aren't too many. In a large project the output could be large enough
>>> to drown out other possibly more important warnings though.
>>
>> Although I would suggest that warnings from the linker are a relatively
>> rare occurrence.  Unlike say a compiler ... :-)
>>
>> In answer to Szabolcs's question:
>>
>>> does -z ibt warn on x86_64?
>>
>> No - it does not.  On the other hand, it does not force the enablement
>> of ibt either.  In fact it appears to operate in the other way.  Linking
>> x86 binaries without specifying "-z ibt" or "-z ibtplt" on the command
>> line will stop the linker from creating IBT enabled PLT entries, even if
>> all of the input object files would support them.
> 
> Maybe that comes automatically from the compiler driver though a quick
> grep doesn't find me anything in the x86 backend.
> 

My understanding on this is a bit different though! Take 
property-x86-ibt4.d test for example where a source without IBT note is 
linked with -z ibt and it gives out an IBT note (and no error/warning). 
Have I missed something?
>>
>>
>> So - if we want to have the same behaviour in the AArch64 linker as we
>> currently have in the x86_64 linker, then how about this:
> 
> Speaking for myself, that's a nice to have. I am all for commonality but
> if one choice is a better technical one and lesser work overall (see
> below) , it may make sense to revisit the x86 decision but that's not my
> call :)
> 
> 
>>
>>     * Without any specific command line options BTI and PAC are not
>>       enabled.  (Ie the dynamic tags are not added to the dynamic section).
> 
> But that in my book feels like more porting work for packagers - surely
> adding a linker flag to default passing on the flags from input object
> files to output ones is more work for all the packagers in the world.
> 
> I would prefer that if all input object files were marked with the BTI,
> the output had the flags on by default. If there was a missing object
> file, the linker should not mark the output file as BTI aware but should
> (up for grabs) warn that the link step missed things out. As you say
> linker warnings are rarer than compiler warnings and hopefully folks
> would pay attention.
> 

Personally I would also prefer if the default behavior for the linker is 
also to do BTI markings without any user options. But this does mean 
that we are going a different way from the existing x86_64 behavior.

> It's only when things go wrong that folks have to intervene to
> investigate / diagnose issues. Otherwise we'd be scratching our heads or
> have to add an additional configure flag to get this default behaviour ?
> 
> 
>>
>>     * With --bti specified, BTI is enabled in the output provided that
>>       the BTI note was found in all of the input files.  If one or more
>>       input files are missing the note, BTI is not enabled, no warnings
>>       are generated, *but* an entry is made in the linker map file indicating
>>       which object(s) caused BTI not to be enabled.  (Assuming that a
>>       linker map file is being generated).  This also matches the current
>>       behaviour of the x86_64 linker.
> 
> I feel this option is superfluous.
> 
>>
>>     * With --force-bti, BTI is enabled even if there are input files
>>       without the BTI note.  In this case, any file without the note
>>       triggers a warning message from the linker.
> 
> Thus in summary I would suggest renaming --bti to --force-bti and
> continue with existing behaviour.

I agree that --force-bti looks like a more appropriate name for the 
option. I am open to the idea of dropping --bti-nowarn 
(--force-bti-nowarn) assuming that if need be, users can ignore the 
warnings and go on doing what they want anyway.

@Nick, I hope that even though staying co-ordinated with x86_64 is 
desirable (to me as well in my personal opinion), our reasoning on the 
differences is convincing enough!

Sudi
> 
> 
>>
>>     * Similarly for PAC.  Ie --pac enables the PAC tag if all of the
>>       inputs support it, but no warnings are generated if some do not,
>>       and --force-pac always generates the PAC tag, but warns about
>>       object files that are missing the note.
> 
> As above.
> 
> Ramana
> 
>>
>> What do people think ?
>>
>> Cheers
>>     Nick
>>
>> PS.  Sudi - the code for the patches themselves looks fine to me,
>>     so I have no concerns there.
>