Prelink: Difference between revisions
simplify |
split OSX, Linux discussions |
||
Line 11: | Line 11: | ||
Prebinding looks up [[memory address]]es of [[debug symbol|symbols]] in [[Shared library|libraries]] that the program is using before the program is launched, and stores this information ahead-of-time, so that the computer need not look up (bind) addresses on each launch. |
Prebinding looks up [[memory address]]es of [[debug symbol|symbols]] in [[Shared library|libraries]] that the program is using before the program is launched, and stores this information ahead-of-time, so that the computer need not look up (bind) addresses on each launch. |
||
⚫ | |||
⚫ | Most programs require [[Library (computer science)|libraries]] to function. Libraries can be integrated into a program once, by a [[Linker (computing)|linker]], when it is [[Compiler|compiled]] ([[Static library|static linking]]) or they can be integrated when the program is run by a [[Loader (computing)|loader]], ([[Library (computer science)#Dynamic linking|dynamic linking]]). Dynamic linking has advantages in code size and management, but every time a program is run, the loader needs to find the relevant libraries. Because the libraries can move around in memory, this causes a performance penalty, and the more libraries that need to be resolved, the greater the penalty. prelink reduces this penalty by using the system's [[dynamic linker]] to reversibly perform this linking in advance ("prelinking" the executable file) by [[Relocation (computer science)|relocating]]. Afterward, the program only needs to spend time finding the relevant libraries on being run if, for some reason (perhaps an upgrade), the libraries have changed since being prelinked. |
||
==Mac OS X== |
|||
⚫ | |||
Prebinding has changed a few times within the Mac OS X series. Before 10.2, prebinding only happened during the installation procedure (the aforementioned "Optimizing" stage). From 10.2 through 10.3 the OS checked for prebinding at launch time for applications, and the first time an application ran it would be prebound, making subsequent launches faster. This could also be manually run, which some OS-level installs did. In 10.4, only OS libraries were prebound. In 10.5 and later, Apple replaced prebinding with a [[dyld]] shared [[cache (computing)|cache]] mechanism,<ref>{{cite web | url=http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/10.5/man1/update_prebinding.1.html | title=Manual Page for update_prebinding | publisher=Apple Computer Inc | work=Apple Developer Connection }}</ref> which provided better OS performance. |
Prebinding has changed a few times within the Mac OS X series. Before 10.2, prebinding only happened during the installation procedure (the aforementioned "Optimizing" stage). From 10.2 through 10.3 the OS checked for prebinding at launch time for applications, and the first time an application ran it would be prebound, making subsequent launches faster. This could also be manually run, which some OS-level installs did. In 10.4, only OS libraries were prebound. In 10.5 and later, Apple replaced prebinding with a [[dyld]] shared [[cache (computing)|cache]] mechanism,<ref>{{cite web | url=http://developer.apple.com/mac/library/documentation/Darwin/Reference/ManPages/10.5/man1/update_prebinding.1.html | title=Manual Page for update_prebinding | publisher=Apple Computer Inc | work=Apple Developer Connection }}</ref> which provided better OS performance. |
||
==Linux== |
|||
⚫ | |||
⚫ | |||
'''prelink''' is a [[Free software|free]] [[Computer program|program]] written by [[Jakub Jelínek]] of [[Red Hat]] for [[POSIX]]-compliant [[operating system]]s, principally [[Linux]] (because it modifies [[Executable and Linkable Format|ELF]] [[executable]]s). It is intended to speed up a system by reducing the time a program needs to begin. Actual results have been mixed, but it seems to aid systems with a large number of libraries, such as [[KDE]].<ref> |
'''prelink''' is a [[Free software|free]] [[Computer program|program]] written by [[Jakub Jelínek]] of [[Red Hat]] for [[POSIX]]-compliant [[operating system]]s, principally [[Linux]] (because it modifies [[Executable and Linkable Format|ELF]] [[executable]]s). It is intended to speed up a system by reducing the time a program needs to begin. Actual results have been mixed, but it seems to aid systems with a large number of libraries, such as [[KDE]].<ref> |
||
Line 24: | Line 33: | ||
| accessdate = 2006-05-10 |
| accessdate = 2006-05-10 |
||
}}</ref> |
}}</ref> |
||
⚫ | |||
⚫ | |||
⚫ | Most programs require [[Library (computer science)|libraries]] to function. Libraries can be integrated into a program once, by a [[Linker (computing)|linker]], when it is [[Compiler|compiled]] ([[Static library|static linking]]) or they can be integrated when the program is run by a [[Loader (computing)|loader]], ([[Library (computer science)#Dynamic linking|dynamic linking]]). Dynamic linking has advantages in code size and management, but every time a program is run, the loader needs to find the relevant libraries. Because the libraries can move around in memory, this causes a performance penalty, and the more libraries that need to be resolved, the greater the penalty. prelink reduces this penalty by using the system's [[dynamic linker]] to reversibly perform this linking in advance ("prelinking" the executable file) by [[Relocation (computer science)|relocating]]. Afterward, the program only needs to spend time finding the relevant libraries on being run if, for some reason (perhaps an upgrade), the libraries have changed since being prelinked. |
||
== Randomization == |
== Randomization == |
Revision as of 20:37, 21 November 2015
This article has multiple issues. Please help improve it or discuss these issues on the talk page. (Learn how and when to remove these messages)
|
Prebinding, also called prelinking, is a method for speeding up a system by reducing the time a program needs to begin.
Prebinding is a method for reducing the time it takes to launch executables in the Mach-O file format. For example, Mac OS X does this in the "Optimizing" stage of installing system software or certain applications.
Prebinding looks up memory addresses of symbols in libraries that the program is using before the program is launched, and stores this information ahead-of-time, so that the computer need not look up (bind) addresses on each launch.
Method
Most programs require libraries to function. Libraries can be integrated into a program once, by a linker, when it is compiled (static linking) or they can be integrated when the program is run by a loader, (dynamic linking). Dynamic linking has advantages in code size and management, but every time a program is run, the loader needs to find the relevant libraries. Because the libraries can move around in memory, this causes a performance penalty, and the more libraries that need to be resolved, the greater the penalty. prelink reduces this penalty by using the system's dynamic linker to reversibly perform this linking in advance ("prelinking" the executable file) by relocating. Afterward, the program only needs to spend time finding the relevant libraries on being run if, for some reason (perhaps an upgrade), the libraries have changed since being prelinked.
Mac OS X
On Mac OS X the process is known as prebinding.
Prebinding has changed a few times within the Mac OS X series. Before 10.2, prebinding only happened during the installation procedure (the aforementioned "Optimizing" stage). From 10.2 through 10.3 the OS checked for prebinding at launch time for applications, and the first time an application ran it would be prebound, making subsequent launches faster. This could also be manually run, which some OS-level installs did. In 10.4, only OS libraries were prebound. In 10.5 and later, Apple replaced prebinding with a dyld shared cache mechanism,[1] which provided better OS performance.
Linux
On Linux, the process is known as prelink.
prelink is a free program written by Jakub Jelínek of Red Hat for POSIX-compliant operating systems, principally Linux (because it modifies ELF executables). It is intended to speed up a system by reducing the time a program needs to begin. Actual results have been mixed, but it seems to aid systems with a large number of libraries, such as KDE.[2]
Randomization
prelink will (when run with the "-R" option) randomly select the address base that libraries are loaded at. This makes it more difficult to perform a return-to-libc attack on the system, because the addresses used are unique to that system. The reason prelink does this is because kernel facilities supplying address space layout randomization (ASLR) for libraries cannot be used in conjunction with prelink without defeating the purpose of prelink and forcing the dynamic linker to perform relocations at program load time.
As stated, prelink and per-process library address randomization cannot be used in conjunction. In order to avoid completely removing this security enhancement, prelink supplies its own randomization; however, this does not help a general information leak caused by prelink. Attackers with the ability to read certain arbitrary files on the target system can discover where libraries are loaded in privileged daemons; often libc is enough as it is the most common library used in return-to-libc attacks.
By reading a shared library file such as libc, an attacker with local access can discover the load address of libc in every other application on the system. Since most programs link to libc, the libc library file always has to be readable; any attacker with local access may gather information about the address space of higher privileged processes. Local access may commonly be gained by shell accounts or Web server accounts that allow the use of CGI scripts, which may read and output any file on the system.[citation needed] Directory traversal vulnerabilities can be used by attackers without accounts if CGI script vulnerabilities are available.
Because prelink is often run periodically, typically every two weeks, the address of any given library has a chance of changing over time. prelink is often used in an incremental mode in which already prelinked libraries are not altered unless absolutely necessary, so a library may not change its base address when prelink is re-run. This gives any address derived a half-life of the period in which prelink is run. Also note that if a new version of the library is installed, the addresses change.
Jakub Jelínek points out that position independent executables (PIE) ignore prelinking on Red Hat Enterprise Linux and Fedora, and recommends that network and SUID programs be built PIE to facilitate a more secure environment.
Issues
Occasionally prelinking can cause issues with application checkpoint and restart libraries like blcr,[3] as well as other libraries (like OpenMPI) that use blcr internally. Specifically when checkpointing a program on one host, and trying to restart on a different host, the restarted program may fail with a segfault due to differences in host-specific library memory address randomization.[4] [5]
See also
- Dynamic binding
- Library (computing)
- Linker (computing)
- Loader (computing)
- Object file
- Relocation
- Static library
- Prefetcher
References
- ^ "Manual Page for update_prebinding". Apple Developer Connection. Apple Computer Inc.
- ^ Crasta, James (2004-05-17). "ELF Prelinking and what it can do for you". Retrieved 2006-05-10.
- ^ blcr
- ^ "BLCR FAQ". Retrieved 2012-01-05.
- ^
Hursey, Josh (2011-12-29). "segfault when resuming on different host". OpenMPI Users (Mailing list). Retrieved 2012-01-05.
{{cite mailing list}}
: Unknown parameter|mailinglist=
ignored (|mailing-list=
suggested) (help)[unreliable source?]
- A detailed explanation of prebinding
Further reading
- Jelínek, Jakub (2004-03-04). "Prelink" (PDF). Draft 0.7. Retrieved 2006-07-14.
{{cite journal}}
: Cite journal requires|journal=
(help)
External links
- Linux Administration and Privileged Commands Manual : prelink ELF shared libraries and binaries to speed up startup time –
- Riis, Quintin (2008-06-15). "Speed up application load time in Ubuntu Linux Hardy Heron using prelink: HOWTO and benchmarks (mention in ubuntuforums/original link is dead)". Retrieved 2008-08-22.
- Jones, Stefan (2007-04-02). "Gentoo Linux Prelink Guide". Retrieved 2006-05-10.
- John Richard Moser (2006-07-05). "Prelink and Address Space Randomization". Retrieved 2006-07-13.