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

Message ID 08762e41-1e80-a504-d840-f8715ea59a50@arm.com
Headers show
Series
  • Add support for AArch64 BTI and PAC in the linker
Related show

Message

Sudakshina Das March 6, 2019, 10:26 a.m.
Hi

This patch series is aimed at giving support for the new Armv8.3-A 
Pointer Authentication and Armv8.5-A Branch Target Identification 
feature in the linker.

In order to support these, we propose to make the following changes:
1) We have defined .note.gnu.property for AArch64.
2) We have defined a new Program Property type
GNU_PROPERTY_AARCH64_FEATURE_1_AND and used 2 bits to represent
BTI and PAC respectively.
   - GNU_PROPERTY_AARCH64_FEATURE_1_BTI
   - GNU_PROPERTY_AARCH64_FEATURE_1_PAC (We have only reserved this bit
     for now.)
3) We also need custom PLTs when these features are turned on and thus
we have defined the following processor-specific dynamic array tags:
   - DT_AARCH64_BTI_PLT
   - DT_AARCH64_PAC_PLT
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

Command line options:
We introduce a new set of command line options for the linker in order 
to support the correct PLTs
1) --pac-plt : In the presence of this option, the linker uses a PAC 
enabled PLT. It also uses the dynamic tag DT_AARCH64_PAC_PLT to reflect 
the same. Other tools like Objdump can use this to determine the size of 
the PLTs.
2) --bti: In the presence of this option, the linker enables BTI with 
the GNU_PROPERTY_AARCH64_FEATURE_1_BTI feature and also uses a BTI 
enabled PLT. It also uses the dynamic tag DT_AARCH64_BTI_PLT to reflect 
the choice of the PLTs. Other tools like Objdump can use this to 
determine the size of the PLTs. Using this option can give a warning if 
not all input objects are marked with GNU_PROPERTY_AARCH64_FEATURE_1_BTI.
3)--bti-nowarn - Same as above but does not emit any warnings.

In terms of the PLTs, in the presence of both --pac-plt and 
--bti/--bti-nowarn, the linker chooses the PLTs protected with both BTI 
and PAC and uses both DT_AARCH64_PAC_PLT and DT_AARCH64_BTI_PLT.

Interaction between Command line arguments and GNU NOTE section
1) For PAC, in the presence of --pac-plt along with BIND_NOW, the linker 
can choose to ignore the pac-plt directive and use smaller PLTs without 
compromising on security,
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 following patches implement these changes as follows:
[1/4] Add support for GNU PROPERTIES in AArch64 for BTI and PAC:
[2/4] Add --bti-nowarn to enable BTI without warning and to select BTI 
enabled PLTs
[3/4] Add --bti to enable BTI and select BTI enabled PLTs but also warn 
for missing NOTE sections.
[4/4] Add --pac-plt to enable PLTs protected with PAC.

This is my first time making such intrusive changes to the linker. 
Please be kind :P

Thanks
Sudi

Comments

Nick Clifton March 7, 2019, 12:37 p.m. | #1
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
Sudakshina Das March 7, 2019, 2:28 p.m. | #2
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

>
Peter Smith March 7, 2019, 3:26 p.m. | #3
On Thu, 7 Mar 2019 at 14:28, Sudakshina Das <Sudi.Das@arm.com> wrote:
>

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


I've got LLD work on my backlog at the moment. It will likely need to
be coordinated with support for Intel CET
(https://reviews.llvm.org/D58102), which introduces .note.gnu.property
to LLD. Gold is of a lower priority right now, at least for Linaro,
with the most likely outcome that it will be worked on when a project
needs it, most likely when this feature is present in platforms that
people use gold to build applications with.

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

>


My initial thought is that if there is more than one
.note.gnu.property section in the executable then the static linker
didn't understand the section and hence we can't assume it did any of
the required actions like producing different PLT sections. Hence I
think acting as if there were no .note.gnu.property sections present
at all would be a sensible choice.

Peter
Nick Clifton March 7, 2019, 3:33 p.m. | #4
Hi Sudi,

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


OK, so just to be clear, with --bti or --bti-nowarn the output will be
given the BTI tag *even if* some of the input files do not have the BTI note ?

This sounds like a serious potential problem.  If BTI is enabled and a
particular object file has not been built with BTI support enabled, then
won't any function calls into that object file fail ?



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

>> for each individual patch.


[These will probably be tomorrow now as I am a little bit swamped with other things today]

Cheers
  Nick
Nick Clifton March 7, 2019, 3:35 p.m. | #5
Hi Peter,

> I've got LLD work on my backlog at the moment. It will likely need to

> be coordinated with support for Intel CET


That makes sense.

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


> My initial thought is that if there is more than one

> .note.gnu.property section in the executable then the static linker

> didn't understand the section and hence we can't assume it did any of

> the required actions like producing different PLT sections. Hence I

> think acting as if there were no .note.gnu.property sections present

> at all would be a sensible choice.


Agreed.  I would just like to see this clearly specified in the documentation
so that other linker maintainers know where they stand.

Cheers
  Nick
Szabolcs Nagy March 7, 2019, 3:49 p.m. | #6
On 07/03/2019 15:35, Nick Clifton wrote:
>>>> 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).

> 

>> My initial thought is that if there is more than one

>> .note.gnu.property section in the executable then the static linker

>> didn't understand the section and hence we can't assume it did any of

>> the required actions like producing different PLT sections. Hence I

>> think acting as if there were no .note.gnu.property sections present

>> at all would be a sensible choice.

> 

> Agreed.  I would just like to see this clearly specified in the documentation

> so that other linker maintainers know where they stand.


so arm decided to use the "gnu property" thing to mark elf modules.
this means the behaviour should be mostly decided by "gnu" i think.

in this case if linkers don't merge gnu property notes, that sounds
like a processor independent problem so ideally the solution would
be the same across targets. (i.e. x86_64 and aarch64 should behave
consistently)

in any case this belongs to either an os specific sysv abi
document (i.e. linux-abi maintained by H.J.Lu) or processor
specific sys v abi (arm has not published this yet) because
those describe dynamic linking behaviour. (the arm elf abi
does not cover dynamic linking)
Sudakshina Das March 7, 2019, 5:53 p.m. | #7
Hi Nick

On 07/03/2019 15:33, Nick Clifton wrote:
> Hi Sudi,

> 

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

> 

> OK, so just to be clear, with --bti or --bti-nowarn the output will be

> given the BTI tag *even if* some of the input files do not have the BTI note ?

> 


Yes
> This sounds like a serious potential problem.  If BTI is enabled and a

> particular object file has not been built with BTI support enabled, then

> won't any function calls into that object file fail ?

> 


The linker is capable of doing the right thing on its own without any 
user option. It will silently remove the BTI note on the output if there 
are objects with missing BTI note section. The user options are an 
indication of what they want, *to turn on BTI*. They can use --bti, 
where the linker will complain about the missing BTI marking and they 
can go back and check the objects that need recompiling or use 
--bti-nowarn when they are sure that even if there is any object with 
missing BTI note section it is still safe to turn on BTI (or they still 
want to turn on BTI). We think that these options would be most helpful 
in early deployment.

Sudi

> 

> 

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

>>> for each individual patch.

> 

> [These will probably be tomorrow now as I am a little bit swamped with other things today]

> 

> Cheers

>    Nick

>
Nick Clifton March 8, 2019, 10:07 a.m. | #8
Hi Sudi,

>> OK, so just to be clear, with --bti or --bti-nowarn the output will be

>> given the BTI tag *even if* some of the input files do not have the BTI note ?


> Yes


> can go back and check the objects that need recompiling or use 

> --bti-nowarn when they are sure that even if there is any object with 

> missing BTI note section it is still safe to turn on BTI (or they still 

> want to turn on BTI). We think that these options would be most helpful 

> in early deployment.


OK, well I get the --bti option then, but I still think that --bti-nowarn
is a mistake.  Given that --bti will only generate warnings if there are
object files without the BTI note, and warnings can be ignored, I do not
see the need for --bti-nowarn.  Plus using --bti-nowarn could potentially
cause problems if the developer forgets (or does not know) that it is 
enabled, and they end up thinking that they are creating BTI enabled 
binaries when in fact they are not.

If a developer really wants to skip the warnings they could pipe the
output from the linker through a grep that eliminates them.  Which would
have the added benefit of being more visible in the output logs of a 
complex build than a single command line option.

Cheers
  Nick
Szabolcs Nagy March 8, 2019, 11:08 a.m. | #9
On 08/03/2019 10:07, Nick Clifton wrote:
> Hi Sudi,

> 

>>> OK, so just to be clear, with --bti or --bti-nowarn the output will be

>>> given the BTI tag *even if* some of the input files do not have the BTI note ?

> 

>> Yes

> 

>> can go back and check the objects that need recompiling or use 

>> --bti-nowarn when they are sure that even if there is any object with 

>> missing BTI note section it is still safe to turn on BTI (or they still 

>> want to turn on BTI). We think that these options would be most helpful 

>> in early deployment.

> 

> OK, well I get the --bti option then, but I still think that --bti-nowarn

> is a mistake.  Given that --bti will only generate warnings if there are

> object files without the BTI note, and warnings can be ignored, I do not

> see the need for --bti-nowarn.  Plus using --bti-nowarn could potentially

> cause problems if the developer forgets (or does not know) that it is 

> enabled, and they end up thinking that they are creating BTI enabled 

> binaries when in fact they are not.

> 

> If a developer really wants to skip the warnings they could pipe the

> output from the linker through a grep that eliminates them.  Which would

> have the added benefit of being more visible in the output logs of a 

> complex build than a single command line option.


does -z ibt warn on x86_64?

it is important to allow the user to force bti on
(a non-bti marked object file can easily be compatible
with bti, e.g if there are no indirect branches targeting
it, or somebody might just want to do runtime tests to
find out where are the problematic branches), so at least
one of --bti or --bti-nowarn should be added, it is just
convenience to have them both since there are different
use cases.

i think it's also reasonable to just have one option that
is compatible with the x86_64 behaviour.
Ramana Radhakrishnan March 8, 2019, 11:14 a.m. | #10
On 08/03/2019 10:07, Nick Clifton wrote:
> Hi Sudi,

> 

>>> OK, so just to be clear, with --bti or --bti-nowarn the output will be

>>> given the BTI tag *even if* some of the input files do not have the BTI note ?

> 

>> Yes

> 

>> can go back and check the objects that need recompiling or use 

>> --bti-nowarn when they are sure that even if there is any object with 

>> missing BTI note section it is still safe to turn on BTI (or they still 

>> want to turn on BTI). We think that these options would be most helpful 

>> in early deployment.

> 

> OK, well I get the --bti option then, but I still think that --bti-nowarn

> is a mistake.  Given that --bti will only generate warnings if there are

> object files without the BTI note, and warnings can be ignored, I do not

> see the need for --bti-nowarn.  Plus using --bti-nowarn could potentially

> cause problems if the developer forgets (or does not know) that it is

> enabled, and they end up thinking that they are creating BTI enabled

> binaries when in fact they are not.


Given this conversation, maybe renaming --bti to --force-bti would 
express the intention clearer ?


regards
Ramana
> 

> Cheers

>    Nick

> 

>
Peter Smith March 8, 2019, 11:45 a.m. | #11
On Fri, 8 Mar 2019 at 11:14, Ramana Radhakrishnan
<Ramana.Radhakrishnan@arm.com> wrote:
>

> On 08/03/2019 10:07, Nick Clifton wrote:

> > Hi Sudi,

> >

> >>> OK, so just to be clear, with --bti or --bti-nowarn the output will be

> >>> given the BTI tag *even if* some of the input files do not have the BTI note ?

> >

> >> Yes

> >

> >> can go back and check the objects that need recompiling or use

> >> --bti-nowarn when they are sure that even if there is any object with

> >> missing BTI note section it is still safe to turn on BTI (or they still

> >> want to turn on BTI). We think that these options would be most helpful

> >> in early deployment.

> >

> > OK, well I get the --bti option then, but I still think that --bti-nowarn

> > is a mistake.  Given that --bti will only generate warnings if there are

> > object files without the BTI note, and warnings can be ignored, I do not

> > see the need for --bti-nowarn.  Plus using --bti-nowarn could potentially

> > cause problems if the developer forgets (or does not know) that it is

> > enabled, and they end up thinking that they are creating BTI enabled

> > binaries when in fact they are not.

>

> Given this conversation, maybe renaming --bti to --force-bti would

> express the intention clearer ?

>

>

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. If there
were a way to generically suppress individual warnings then the case
for the separate command line option wouldn't be as good. Having said
that, I the nowarn form isn't as important as just --bti, or as Ramana
says --force-bti.

Peter

> regards

> Ramana

> >

> > Cheers

> >    Nick

> >

> >

>
Nick Clifton March 8, 2019, 12:32 p.m. | #12
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.


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:

  * Without any specific command line options BTI and PAC are not
    enabled.  (Ie the dynamic tags are not added to the dynamic section).

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

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

  * 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.
    
What do people think ?

Cheers
  Nick

PS.  Sudi - the code for the patches themselves looks fine to me,
  so I have no concerns there.
Ramana Radhakrishnan March 8, 2019, 12:44 p.m. | #13
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.
Sudakshina Das March 8, 2019, 1:36 p.m. | #14
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.

>
Nick Clifton March 11, 2019, 12:30 p.m. | #15
Hi Sudi,

>>>> does -z ibt warn on x86_64?

>>>

>>> No - it does not.  


>> Maybe that comes automatically from the compiler driver though a quick

>> grep doesn't find me anything in the x86 backend.


Hmm, true - I cannot find it either.


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


Nope, it must be me.  


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


>> I feel this option is superfluous.


Hmm, OK,

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


It is.   :-)

OK, lets go with enabling BTI automatically, providing that all of
the inputs have the required notes.  The --force-bti option does
what it says, but generates warnings for any input that does not
have a note.

I still think that --force-bti-nowarn would be a dangerous option
to have, but if your toolchain guys really think that it is necessary
then I am not going to object to it any longer.

Patch series with the revised option name(s) approved.

Cheers
  Nick
Sudakshina Das March 13, 2019, 11:49 a.m. | #16
Hi Nick

On 11/03/2019 12:30, Nick Clifton wrote:
> Hi Sudi,

> 

>>>>> does -z ibt warn on x86_64?

>>>>

>>>> No - it does not.

> 

>>> Maybe that comes automatically from the compiler driver though a quick

>>> grep doesn't find me anything in the x86 backend.

> 

> Hmm, true - I cannot find it either.

> 

> 

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

> 

> Nope, it must be me.

> 

> 

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

> 

>>> I feel this option is superfluous.

> 

> Hmm, OK,

> 

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

> 

> It is.   :-)


Thanks :)
> 

> OK, lets go with enabling BTI automatically, providing that all of

> the inputs have the required notes.  The --force-bti option does

> what it says, but generates warnings for any input that does not

> have a note.

> 

> I still think that --force-bti-nowarn would be a dangerous option

> to have, but if your toolchain guys really think that it is necessary

> then I am not going to object to it any longer.

> 

> Patch series with the revised option name(s) approved.


Thank you. I have changed the option name to --force-bti and I have 
dropped the nowarn option. Patch 2 and 3 are thus merged into one and 
committed the series of 3 patches!

Thanks
Sudi

> 

> Cheers

>    Nick

>