Dynamic linker behavior can be modified by setting the
following tunables in the rtld namespace:
Sets the number of supported dynamic link namespaces (see dlmopen).
Currently this limit can be set between 1 and 16 inclusive, the default is 4.
Each link namespace consumes some memory in all thread, and thus raising the
limit will increase the amount of memory each thread uses. Raising the limit
is useful when your application uses more than 4 dynamic link namespaces as
created by dlmopen with an lmid argument of LM_ID_NEWLM.
Dynamic linker audit modules are loaded in their own dynamic link namespaces,
but they are not accounted for in glibc.rtld.nns. They implicitly
increase the per-thread memory usage as necessary, so this tunable does
not need to be changed to allow many audit modules e.g. via LD_AUDIT.
Sets the amount of surplus static TLS in bytes to allocate at program
startup. Every thread created allocates this amount of specified surplus
static TLS. This is a minimum value and additional space may be allocated
for internal purposes including alignment. Optional static TLS is used for
optimizing dynamic TLS access for platforms that support such optimizations
e.g. TLS descriptors or optimized TLS access for POWER (DT_PPC64_OPT
and DT_PPC_OPT). In order to make the best use of such optimizations
the value should be as many bytes as would be required to hold all TLS
variables in all dynamic loaded shared libraries. The value cannot be known
by the dynamic loader because it doesn’t know the expected set of shared
libraries which will be loaded. The existing static TLS space cannot be
changed once allocated at process startup. The default allocation of
optional static TLS is 512 bytes and is allocated in every thread.
Sets the algorithm to use for DSO sorting, valid values are ‘1’ and ‘2’. For value of ‘1’, an older O(n^3) algorithm is used, which is long time tested, but may have performance issues when dependencies between shared objects contain cycles due to circular dependencies. When set to the value of ‘2’, a different algorithm is used, which implements a topological sort through depth-first search, and does not exhibit the performance issues of ‘1’.
The default value of this tunable is ‘2’.
Used to run a program as if it were a setuid process. The only valid value
is ‘1’ as this tunable can only be used to set and not unset
enable_secure. Setting this tunable to ‘1’ also disables all other
tunables. This tunable is intended to facilitate more extensive verification
tests for AT_SECURE programs and not meant to be a security feature.
The default value of this tunable is ‘0’.
The GNU C Library will use either the default architecture ABI flags (that might
contain the executable bit) or the value of PT_GNU_STACK (if present)
to define whether to mark the stack non-executable and if the program or
any shared library dependency requires an executable stack the loader will
change the main stack permission if kernel starts with a non-executable stack.
The glibc.rtld.execstack can be used to control whether an executable
stack is allowed from the main program. Setting the value to 0 disables
the ABI auto-negotiation (meaning no executable stacks even if the ABI or ELF
header requires it), while 1 enables auto-negotiation (although the
program might not need an executable stack).
When executable stacks are not allowed, and if the main program requires it, the loader will fail with an error message.
Some systems do not have separate page protection flags at the hardware level for read access and execute access (sometimes called read-implies-exec). This mode can also be enabled on certain systems where the hardware supports separate protection flags. The the GNU C Library tunable configuration is independent of hardware capabilities and kernel configuration.
NB: Trying to load a dynamic shared library with dlopen or
dlmopen that requires an executable stack will always fail if the
main program does not require an executable stack at loading time. This
is enforced regardless of the tunable value.