Re: [PATCH 1/1] aarch64:fix aarch64_tlsdesc conflict handling

[Mark Hatle <mark dot hatle at windriver dot com>]

On 11/6/15 9:56 AM, Szabolcs Nagy wrote:
> On 06/11/15 06:59, Maninder Singh wrote:
>> This patch fixes aarch64_tlsdesc conflict handling in
>> .gnu.conflict section. This patch is added to support prelink
>> on aarch64 architecture.
>> http://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/commit
>> /?h=cross_prelink_aarch64&id=2e83ded69171d87b76bcffaeffbd2cdb532663de
>>
>> Signed-off-by: Vaneet Narang <v.narang@samsung.com>
>> Signed-off-by: Maninder Singh <maninder1.s@samsung.com>
>> ---
>>   sysdeps/aarch64/dl-machine.h |   17 ++++++++++++++---
>>   1 files changed, 14 insertions(+), 3 deletions(-)
>>
>> diff --git a/sysdeps/aarch64/dl-machine.h b/sysdeps/aarch64/dl-machine.h
>> index 217e179..70c112d 100644
>> --- a/sysdeps/aarch64/dl-machine.h
>> +++ b/sysdeps/aarch64/dl-machine.h
>> @@ -290,9 +290,20 @@ elf_machine_rela (struct link_map *map, const ElfW(Rela) *reloc,
>>   #ifndef RTLD_BOOTSTRAP
>>   	    if (! sym)
>>   	      {
>> -		td->arg = (void*)reloc->r_addend;
>> -		td->entry = _dl_tlsdesc_undefweak;
>> -	      }
>> +			ElfW(Rela) * conflict_start = NULL;
>> +			ElfW(Rela) * conflict_end = NULL;
>> +			if ( l->l_info [ADDRIDX (DT_GNU_CONFLICT)])
>> +		      {
>> +				conflict_start = (ElfW(Rela) *) map->l_info [ADDRIDX (DT_GNU_CONFLICT)]->d_un.d_ptr;
>> +				conflict_end = conflict_start +
>> +								map->l_info [VALIDX (DT_GNU_CONFLICTSZ)]->d_un.d_val;
>> +		      }
>> +			td->arg = (void*)reloc->r_addend;
>> +			if(conflict_start <= reloc && conflict_end >= reloc)
>> +				td->entry = _dl_tlsdesc_return;
>> +			else
>> +				td->entry = _dl_tlsdesc_undefweak;
> 
> this code could be better organised.
> (to have minimal impact on the non-prelinked case, e.g by
> leaving the original code alone and moving all the new
> special casing behind one if that checks for DT_GNU_CONFLICT.)
> 
> isn't it possible to just pass a dummy sym in
> _dl_resolve_conflicts so we don't need any special
> target specific code?
> 
> is x86_64 tlsdesc also broken with prelinking?

As far as I am ware the tlsdesc on x86_64 is working properly.  The current set
of prelink tests pass.  I've not verified that that specific issue is tested for
however.  (Current tests are in the 'testsuite' directory and run via 'make
check'.  These tests recently exposed a problem between ld.so in glibc 2.22 and
the prelink interface BZ # 19178.  This interface problem affected all
i*86/x86_64 and arm/aarch64 systems.)

The current incarnation of the prelinker is available at
git://git.yoctoproject.org/prelink-cross

Where the 'master' branch is a replacement for the older prelink project (in
that it is standalone and needs to be compiled and run on the platform it is
targeting.)

While the 'cross_prelink' branch is the same code with the addition of an
emulated RTLD (prelink-rtld) as well as some code to handle sysroots.

(I've been maintaining an embedded oriented variant of the prelinker for some
time, but the upstream development seems to have stopped -- so I've attempted to
take over the core development as well.  If anyone is interested, see the git
repository or contact me for more information.)

> who uses prelinking and why? (it has various issues
> including defeating security measures..)

Anyone who has memory usage requirements (low memory available) or load time
performance requirements can benefit from the prelinker.

The prelinker does not 'defeat' security measures.  If your design needs to use
ASLR, then the prelinker is not for you.  (I won't debate the merits of ASLR,
other then to say it has tradeoffs which need to be decided on by the platform
integrator and it's not always the right answer.)

When prelinking a small embedded system, it's fairly typical to see 1/2 MB or
more in additional usable memory available after the system boot.  This is due
to fewer COW pages for the core system services such as sysvinit or systemd,
udev, etc.  In addition the load time of the components is reduced (as shown by
LD_DEBUG=statistics.)  These figures vary by system configuration (process
choice) and number of running services of course.

On a high end system with lots of memory and few load time speed requirements,
prelinker may not provide the benefits justifying it's use -- but on embedded
systems where performance and memory usage are often key software requirements
the prelinker can make the difference between a CPU core being adequate for the
task -- or a product doomed to failure.

>> +	      }
>>   	    else
>>   #endif
>>   	      {
>>
>