### 39.3 Dynamic Linking Tunables ¶

Tunable namespace: glibc.rtld ¶

  Dynamic linker behavior can be modified by setting the following tunables in the `rtld` namespace:

Tunable: glibc.rtld.nns ¶

  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`.

Tunable: glibc.rtld.optional_static_tls ¶

  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.

Tunable: glibc.rtld.dynamic_sort ¶

  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`’.

Tunable: glibc.rtld.enable_secure ¶

  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`’.

Tunable: glibc.rtld.execstack ¶

  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), `1` enables auto-negotiation (although the program might not need an executable stack), while `2` forces an executable stack at process start. This is provided for compatibility reasons, when the program dynamically loads modules with `dlopen` which require 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 can be worked around by setting the tunable to `2`, where the stack is always executable.