[PATCH] ARM: force linker to use PIC veneers

On Tue, 24 Mar 2015, Ard Biesheuvel wrote:

On 24 March 2015 at 16:16, Nicolas Pitre [off-list ref] wrote:

quoted

On Tue, 24 Mar 2015, Ard Biesheuvel wrote:

quoted

On 24 March 2015 at 13:22, Dave Martin [off-list ref] wrote:

quoted

How many such veneers get added in the your kernel configuration, and
how many are actually necessary (i.e., calls between MMU-off code and
elsewhere)?

Very few. In addition to the example (which will be addressed in
another way regardless) there are some resume functions that get
allocated in .data, and those would need it as well.

What are they? I thought we removed all instances of those already.

quoted

I have also proposed b_far/bl_far macros that could be used there as
well.

Could the automatic veneer insertion replace the unconditional
b_far/bl_far usage?  The former would be preferable to the later.

Agreed. I am not entirely sure why those functions don't get a veneer.
Perhaps simply because .data is not annotated as executable?

Frankly, I don't really understand the purpose of putting those in
.data in the first place. but if they need to remain there, I can try
to figure out how to get the linker to emit veneers for those as well.

I'm guilty of introducing the first instance of code in .data back in 
... hrm ... 1998 or so.  I wasn't as experienced in ARM assembly back 
then and the resume code needed to fetch its context data while the MMU 
was off. So the easy way was simply to put the code next to the data 
block and get its address using adr.

These days we know how to write code to obtain position independent 
memory addresses at run time. One such example is commit b4e6153704 
where the bl relocation also exceeded its range.  But I thought I had 
converted all those instances already.


Nicolas