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

[Ramana Radhakrishnan <Ramana.Radhakrishnan@arm.com>]

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.

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

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.


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