The state of prelinking support

The state of prelinking support

[Florian Weimer]

Does prelinking still work?  Is anyone testing it reguarly?

Fedora has removed the program (prelink) that generates the necessary
metadata/DSO changes quite some time ago.  Debian's most recent release
doesn't include it, either.

Thanks,
Florian

Re: The state of prelinking support

[Joseph Myers]

On Mon, 23 Aug 2021, Florian Weimer via Libc-alpha wrote:

> Does prelinking still work?  Is anyone testing it reguarly?

It's maintained to a limited extent in Yocto - 
https://git.yoctoproject.org/cgit/cgit.cgi/prelink-cross/ - though I think 
not used by default and not maintained very actively (and not running the 
prelink testsuite as part of Yocto toolchain testing).  Some users still 
find significant startup time benefits (for specific embedded system 
images or applications) that make it worth using prelink.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: The state of prelinking support

[Mike Frysinger]

On 23 Aug 2021 14:17, Florian Weimer via Libc-alpha wrote:
> Does prelinking still work?  Is anyone testing it reguarly?
> 
> Fedora has removed the program (prelink) that generates the necessary
> metadata/DSO changes quite some time ago.  Debian's most recent release
> doesn't include it, either.

doesn't it completely break with PIE+ASLR ?  i imagine most distros are now
biasing towards those which means prelink doesn't make sense for them anymore.
-mike

Re: The state of prelinking support

[Florian Weimer]

* Mike Frysinger:

> On 23 Aug 2021 14:17, Florian Weimer via Libc-alpha wrote:
>> Does prelinking still work?  Is anyone testing it reguarly?
>> 
>> Fedora has removed the program (prelink) that generates the necessary
>> metadata/DSO changes quite some time ago.  Debian's most recent release
>> doesn't include it, either.
>
> doesn't it completely break with PIE+ASLR ?  i imagine most distros are now
> biasing towards those which means prelink doesn't make sense for them anymore.

It definitely fixes DSO addresses so that remain the same on subsequent
runs.  I don't know what prelink does to ET_DYN executables.

My question wasn't so much whether this is a good idea.  We have some
code in ld.so dedicated to prelinking.  If it's still working for
someone, we can't remove it.

Thanks,
Florian

Re: The state of prelinking support

[Carlos O'Donell]

On 8/27/21 6:49 AM, Florian Weimer via Libc-alpha wrote:
> * Mike Frysinger:
> 
>> On 23 Aug 2021 14:17, Florian Weimer via Libc-alpha wrote:
>>> Does prelinking still work?  Is anyone testing it reguarly?
>>>
>>> Fedora has removed the program (prelink) that generates the necessary
>>> metadata/DSO changes quite some time ago.  Debian's most recent release
>>> doesn't include it, either.
>>
>> doesn't it completely break with PIE+ASLR ?  i imagine most distros are now
>> biasing towards those which means prelink doesn't make sense for them anymore.
> 
> It definitely fixes DSO addresses so that remain the same on subsequent
> runs.  I don't know what prelink does to ET_DYN executables.
> 
> My question wasn't so much whether this is a good idea.  We have some
> code in ld.so dedicated to prelinking.  If it's still working for
> someone, we can't remove it.

I think we should declare the current prelinking implementation officially
unsupported in glibc.

I would be OK in glibc 2.35 to say that prelinking is no longer supported
and remove associated code if it is causing refactoring problems.

If developers want to reduce startup costs we have strategies like criu
that could allow an "application image" to be saved/restored very quickly
at some point inside the loader. I'd be *much* more interested in a criu
"rendezvous" inside ld.so.

-- 
Cheers,
Carlos.