Re: Prelink problems -- need help!

[Mark Hatle <mark.hatle@windriver.com>]

On 10/26/15 11:45 AM, Mark Hatle wrote:
> On 10/26/15 11:10 AM, Phil Blundell wrote:
>> [Cc list trimmed]
>>
>> On Mon, 2015-10-26 at 09:28 -0500, Mark Hatle wrote:
>>> As you can see, pretty much everything is currently broken and I'm
>>> struggling to
>>> find community people with the right skill sets to help me resolve
>>> the issues.
>>
>> I think it's true that prelink is a technology which has largely had
>> its day, and I could well imagine that upstream Red Hat is no longer
>> very interested in it.  https://fedorahosted.org/fesco/ticket/1183 has
>> a summary of some of the reasons why.
>>
>> Before investing any significant amount of time in fixing up prelink
>> (and from what you've described it sounds like it might indeed be a
>> significant effort to get it working again on all platforms) it might
>> be a good idea to make sure we are still convinced that prelink
>> provides useful and meaningful benefits for OE-core users.
>>
> 
> I do think prelink has a purpose.  Especially for embedded systems.
> 
> The biggest reason I see against prelink is ASLR.  I agree 100% that if you want
> ASLR (Address Randomization) you should not be using the prelinker.
> 
> Usually secondary reasons include if you are doing field upgrades at a package
> level -- it means you also need the ability to prelink on the device which cause
> have other performance ramifications and such during this upgrade process.
> 
> I agree with some of the information on the Fedora hosted link you pointed to,
> but disagree with others.
> 
> While some of the modern hashing techniques and such do improve run-time dynamic
> link performance, there is still a hit that we must take.  For devices that need
> quick boot times, quick startup, or are memory constrained, the prelinker can
> still help.  (Memory usage on very small systems is a good example.  Memory
> usage can be reduced in larger applications by reducing the number of
> Copy-on-write pages required to handle the relocation information.)
> 
> I probably would not use the prelinker on a workstation/server any longer.  I
> might not use it on a 'larger' embedded system, but on a more traditional
> embedded system I do think it still has merit.
> 
> (Probably a discussion for the future, due to the ASLR, is should the prelinker
> be enabled by default -- even if it works -- but that is a discussion for later.)
> 
>> If the answer to that is yes then I probably could spare a bit of time
>> to look at the ARM and MIPS issues at least.
> 
> I can certainly use any help you have.  I have someone looking into the ARM
> issues with me.  It APPEARS the primary behavior there has to do with IFUNC
> behavior to things like memcpy has changed, causing the prelinker to do the
> wrong thing(s).  But I have few additional details at this time.
> 
> I've reached out to parts of the MIPS community for help, but we'll see if I get
> any type of response.  (MIPS, especially 32-bit, I'm very surprised has broken
> recently.  I haven't seen many changes in regard to the way binaries are loaded
> on MIPS -- so the issue must be related to a more fundamental optimization or
> bug in the prelink.)
> 
> Thanks for the offer, let me know if you find anything.  I'll certainly respond
> as I make progress trying to go through the issues.

I just wanted to update folks on where I'm at.

On the Intel IA32 architecture, the problem appears to have been triggered by
the ELF_RTYPE_CLASS_EXTERN_PROTECTED_DATA that went in after March of this year.
 I've not been able to track down what is causing the bad behavior -- but fully
dropping support for that class type allows the prelink to "mostly work".

On ARM the issues appear to have some problem related to IFUNCs, but I still
don't have any data beyond that at this point.

> --Mark
> 
>> p.
>>
>