Hardware Capability Tunables (The GNU C Library)

### 39.6 Hardware Capability Tunables ¶

Tunable namespace: glibc.cpu ¶

  Behavior of the GNU C Library can be tuned to assume specific hardware capabilities by setting the following tunables in the `cpu` namespace:

Tunable: glibc.cpu.hwcaps ¶

  The `glibc.cpu.hwcaps=-xxx,yyy,-zzz...` tunable allows the user to enable CPU/ARCH feature `yyy`, disable CPU/ARCH feature `xxx` and `zzz` where the feature name is case-sensitive and has to match the ones in `sysdeps/x86/include/cpu-features.h`.

  On s390x, the supported HWCAP and STFLE features can be found in `sysdeps/s390/cpu-features.c`. In addition the user can also set a CPU arch-level like `z13` instead of single HWCAP and STFLE features.

  On powerpc, the supported HWCAP and HWCAP2 features can be found in `sysdeps/powerpc/dl-procinfo.c`.

  On loongarch, the supported HWCAP features can be found in `sysdeps/loongarch/cpu-tunables.c`.

  This tunable is specific to i386, x86-64, s390x, powerpc and loongarch.

Tunable: glibc.cpu.cached_memopt ¶

  The `glibc.cpu.cached_memopt=[0|1]` tunable allows the user to enable optimizations recommended for cacheable memory. If set to `1`, the GNU C Library assumes that the process memory image consists of cacheable (non-device) memory only. The default, `0`, indicates that the process may use device memory.

  This tunable is specific to powerpc, powerpc64 and powerpc64le.

Tunable: glibc.cpu.name ¶

  The `glibc.cpu.name=xxx` tunable allows the user to tell the GNU C Library to assume that the CPU is `xxx` where xxx may have one of these values: `generic`, `thunderxt88`, `thunderx2t99`, `thunderx2t99p1`, `ares`, `emag`, `kunpeng`, `a64fx`.

  This tunable is specific to aarch64.

Tunable: glibc.cpu.x86_data_cache_size ¶

  The `glibc.cpu.x86_data_cache_size` tunable allows the user to set data cache size in bytes for use in memory and string routines.

  This tunable is specific to i386 and x86-64.

Tunable: glibc.cpu.x86_shared_cache_size ¶

  The `glibc.cpu.x86_shared_cache_size` tunable allows the user to set shared cache size in bytes for use in memory and string routines.

Tunable: glibc.cpu.x86_non_temporal_threshold ¶

  The `glibc.cpu.x86_non_temporal_threshold` tunable allows the user to set threshold in bytes for non temporal store. Non temporal stores give a hint to the hardware to move data directly to memory without displacing other data from the cache. This tunable is used by some platforms to determine when to use non temporal stores in operations like memmove and memcpy.

  This tunable is specific to i386 and x86-64.

Tunable: glibc.cpu.x86_memset_non_temporal_threshold ¶

  The `glibc.cpu.x86_memset_non_temporal_threshold` tunable allows the user to set threshold in bytes for non temporal store in memset. Non temporal stores give a hint to the hardware to move data directly to memory without displacing other data from the cache. This tunable is used by some platforms to determine when to use non temporal stores memset.

  This tunable is specific to i386 and x86-64.

Tunable: glibc.cpu.x86_rep_movsb_threshold ¶

  The `glibc.cpu.x86_rep_movsb_threshold` tunable allows the user to set threshold in bytes to start using "rep movsb". The value must be greater than zero, and currently defaults to 2048 bytes.

  This tunable is specific to i386 and x86-64.

Tunable: glibc.cpu.x86_rep_stosb_threshold ¶

  The `glibc.cpu.x86_rep_stosb_threshold` tunable allows the user to set threshold in bytes to start using "rep stosb". The value must be greater than zero, and currently defaults to 2048 bytes.

  This tunable is specific to i386 and x86-64.

Tunable: glibc.cpu.x86_ibt ¶

  The `glibc.cpu.x86_ibt` tunable allows the user to control how indirect branch tracking (IBT) should be enabled. Accepted values are `on`, `off`, and `permissive`. `on` always turns on IBT regardless of whether IBT is enabled in the executable and its dependent shared libraries. `off` always turns off IBT regardless of whether IBT is enabled in the executable and its dependent shared libraries. `permissive` is the same as the default which disables IBT on non-CET executables and shared libraries.

  This tunable is specific to i386 and x86-64.

Tunable: glibc.cpu.x86_shstk ¶

  The `glibc.cpu.x86_shstk` tunable allows the user to control how the shadow stack (SHSTK) should be enabled. Accepted values are `on`, `off`, and `permissive`. `on` always turns on SHSTK regardless of whether SHSTK is enabled in the executable and its dependent shared libraries. `off` always turns off SHSTK regardless of whether SHSTK is enabled in the executable and its dependent shared libraries. `permissive` changes how dlopen works on non-CET shared libraries. By default, when SHSTK is enabled, dlopening a non-CET shared library returns an error. With `permissive`, it turns off SHSTK instead.

  This tunable is specific to i386 and x86-64.

Tunable: glibc.cpu.prefer_map_32bit_exec ¶

  When this tunable is set to `1`, shared libraries of non-setuid programs will be loaded below 2GB with MAP_32BIT.

  Note that the `LD_PREFER_MAP_32BIT_EXEC` environment is an alias of this tunable.

  This tunable is specific to 64-bit x86-64.

Tunable: glibc.cpu.plt_rewrite ¶

  When this tunable is set to `1`, the dynamic linker will rewrite the PLT section with 32-bit direct jump. When it is set to `2`, the dynamic linker will rewrite the PLT section with 32-bit direct jump and on APX processors with 64-bit absolute jump.

  This tunable is specific to x86-64 and effective only when the lazy binding is disabled.

Tunable: glibc.cpu.aarch64_bti ¶

  This tunable controls Branch Target Identification (BTI) handling for the process. This handling is implemented via protecting the memory mapping with `PROT_BTI` for modules that are marked with the appropriate ELF property `GNU_PROPERTY_AARCH64_FEATURE_1_BTI` (see Program Loading in https://github.com/ARM-software/abi-aa/blob/main/sysvabi64/sysvabi64.rst).

  Accepted values are:

  0 = permissive: BTI protection is enabled only for modules that have BTI marking (default).

  1 = enforced: if a module that does not have BTI marking is loaded, it is an error (either a process abort or a `dlopen` error if this binary is loaded via `dlopen`).

Tunable: glibc.cpu.aarch64_gcs ¶

  This tunable controls Guarded Control Stack (GCS) for the process.

  Accepted values are:

  - `0` = disabled: do not enable GCS.
  - `1` = enforced: check markings and abort if any binary is not marked, otherwise enable GCS and lock all GCS features.
  - `2` = optional: check markings but keep GCS off if any binary is unmarked, otherwise enable GCS but do not lock any GCS features.
  - `3` = override: enable GCS and lock all GCS features, markings are ignored.

  If unmarked binary is loaded via `dlopen` when GCS is enabled and markings are not ignored (i.e. `aarch64_gcs == 1` or `2`), then `dlopen` will return an error.

  Default is `0`, so GCS is disabled by default.

  This tunable is specific to AArch64. On systems that do not support Guarded Control Stack this tunable has no effect.

  GCS features (or operations on shadow stack) such as `STATUS` (i.e. enabling and disabling GCS), `WRITE`, and `PUSH`, will be locked for the `enforced` and `override` tunable values.

  Before enabling GCS for the process the value of this tunable is checked and depending on it the following outcomes are possible.

  - `aarch64_gcs == 0`: GCS will remain disabled and GCS markings will not be checked for any binaries.
  - `aarch64_gcs == 1`: GCS markings will be checked for all binaries loaded at startup and, only if all binaries are GCS-marked, GCS will be enabled and all GCS features will be locked. If any of the binaries are not GCS-marked, the process will abort. Subsequent call to `dlopen` for an unmarked binary will result in `dlopen` returning an error.
  - `aarch64_gcs == 2`: GCS markings will be checked for all binaries loaded at startup and, if any of such binaries are not GCS-marked, GCS will not be enabled and there will be no more checks for GCS marking. If all binaries loaded at startup are GCS-marked, then GCS will be enabled but GCS features will not be locked. In this case a call to `dlopen` for an unmarked binary will result in `dlopen` returning an error.
  - `aarch64_gcs == 3`: GCS will be enabled and all GCS features will be locked. GCS markings will not be checked for any binaries.