Раскрытие токена rpath¶

Динамический компоновщик распознаёт определённые строковые токены в значении rpath (DT_RPATH или DT_RUNPATH). Эти строки заменяются на:

$ORIGIN (или ${ORIGIN})

Она раскрывается в каталог, содержащий программу или общий объект. Таким образом, приложение, расположенное в somedir/app может компилироваться с

gcc -Wl,-rpath,'$ORIGIN/../lib'

для того, чтобы оно могло найти связанный общий объект в somedir/lib и не важно где в иерархии каталогов будет находиться somedir. Это облегчает создание приложений «под ключ», которые вместо установки в специальные каталоги, можно просто распаковать в любой каталог, и они всё равно найдут свои общие объекты.

$LIB (или ${LIB})

Она раскрывается в lib или lib64, в зависимости от архитектуры (например, на x86-64 она заменяется на lib64, а на x86-32 она заменяется на lib).

$PLATFORM (или ${PLATFORM})

Преобразуется в строку, соответствующую типу процессора узла (например, «x86_64»). На некоторых архитектурах ядро Linux не предоставляет строку платформы динамическому компоновщику. Значение этой строки берётся из значения AT_PLATFORM вспомогательного вектора (смотрите getauxval(3)).

Безопасный режим выполнения¶

For security reasons, the effects of some environment variables are voided or modified if the dynamic linker determines that the binary should be run in secure-execution mode. (For details, see the discussion of individual environment variables below.) A binary is executed in secure-execution mode if the AT_SECURE entry in the auxiliary vector (see getauxval(3)) has a nonzero value. This entry may have a nonzero value for various reasons, including:

• У процесса различаются реальный и эффективный идентификатор пользователя/группы. Обычно, это происходит в результате выполнения программ с установленным битом set-user-ID или set-group-ID.
• Процесс с пользовательским ID не равным root, выполняет файл, который присваивает мандаты процессу.
• Ненулевое значение может установить Linux Security Module.

Переменные окружения¶

Среди наиболее важных переменных окружения следует выделить следующие:

LD_ASSUME_KERNEL (начиная с glibc 2.2.3)

Каждый общий объект может сообщать динамическому компоновщику о требуемой минимальной версии ядерного ABI (это требование кодируется в разделе ELF note, который можно просмотреть с помощью readelf -n, под меткой NT_GNU_ABI_TAG). Во время выполнения динамический компоновщик определяет версию ABI запущенного ядра и не будет загружать общие объекты, у которых минимальная версия ABI превышает версию ядра.

LD_ASSUME_KERNEL можно использовать, чтобы заставить динамический компоновщик предполагать, что он работает в системе с другой версией ядра ABI. Например, следующая команда заставляет динамический компоновщик при загрузке общих объектов, требуемых myprog, предполагать, что он запущен на Linux с версией 2.2.5:

$ LD_ASSUME_KERNEL=2.2.5 ./myprog
    

В системах, предоставляющих несколько версий общего объекта (в различных каталогах пути поиска) с разными требованиями к минимальной версии ядра ABI, LD_ASSUME_KERNEL может использоваться для выбора версии объекта, которую нужно задействовать (в зависимости от порядка поиска в каталогах).

Исторически, свойство LD_ASSUME_KERNEL наиболее часто использовалось при ручном выборе старых реализаций нитей POSIX LinuxThreads в системах, которые предоставляли и LinuxThreads, и NPTL (в последствии стала базовой в таких системах); смотрите pthreads(7).

LD_BIND_NOW (начиная с glibc 2.1.1)

Если переменная содержит непустую строку, то динамический компоновщик будет искать все символы при запуске программы вместо того, чтобы отложить поиск вызовов функций до момента, когда они встретятся в первый раз. Это полезно при отладке.

LD_LIBRARY_PATH

Список каталогов, в которых будет производиться поиск библиотек ELF в момент выполнения. Элементы списка разделяются двоеточиями или точками с запятой (экранирование этих разделителей не поддерживается).

Данная переменная игнорируется в режиме безопасного выполнения.

Внутри путей, указанных в LD_LIBRARY_PATH, динамический компоновщик раскрывает токены $ORIGIN, $LIB и $PLATFORM (или версии, использующие фигурные скобки вокруг имён) как описано выше в разделе Раскрытие токена rpath. Таким образом, например, следующее значение заставит искать библиотеку в подкаталогах lib или lib64, находящихся ниже каталога, содержащего исполняемую программу:

$ LD_LIBRARY_PATH='$ORIGIN/$LIB' prog
    

(Обратите внимание на одиночные кавычки, которые не позволяют раскрывать $ORIGIN и $LIB как переменные оболочки!)

LD_PRELOAD

A list of additional, user-specified, ELF shared objects to be loaded before all others. The items of the list can be separated by spaces or colons, and there is no support for escaping either separator. This can be used to selectively override functions in other shared objects. The objects are searched for using the rules given under DESCRIPTION.

В режиме безопасного выполнения предварительная загрузка файлов с символами косой черты не выполняется. Кроме того, загружаются общие объекты только из стандартных каталогов поиска и с включённым битом режима set-user-ID (что не типично).

Внутри имён, указанных в списке LD_PRELOAD, динамический компоновщик раскрывает токены $ORIGIN, $LIB и $PLATFORM (или версии, использующие фигурные скобки вокруг имён) как описано выше в разделе Раскрытие токена rpath (также смотрите описание цитирования в LD_LIBRARY_PATH).

LD_TRACE_LOADED_OBJECTS

Если установлена (любое значение), то вместо нормального запуска программы будут выданы её динамические зависимости, как если бы она была запущена ldd(1).

Также существует большое количество более или менее полезных переменных, многие из которых устарели или предназначены только для внутреннего использования.

LD_AUDIT (начиная с glibc 2.4)

A colon-separated list of user-specified, ELF shared objects to be loaded before all others in a separate linker namespace (i.e., one that does not intrude upon the normal symbol bindings that would occur in the process) and there is no support for escaping the separator. These objects can be used to audit the operation of the dynamic linker.

Переменная LD_AUDIT игнорируется в режиме безопасного выполнения.

Динамический компоновщик будет уведомлять общие объекты контроля в так называемых точках контроля — например, при загрузке нового общего объекта, поиске символа или при вызове символа из другого динамического объекта — вызывая соответствующую функцию из общего объекта контроля. Подробности смотрите в rtld-audit(7). Интерфейс контроля в значительной степени совместим с представленным в Solaris, описан в его Руководстве по компоновщику и библиотекам (Linker and Libraries Guide) в главе Интерфейс контроля компоновщика во время выполнения (Runtime Linker Auditing Interface).

Внутри имён, указанных в списке LD_AUDIT, динамический компоновщик раскрывает токены $ORIGIN, $LIB и $PLATFORM (или версии, использующие фигурные скобки вокруг имён) как описано выше в разделе Раскрытие токена rpath (также смотрите описание цитирования в LD_LIBRARY_PATH).

Начиная с glibc 2.13 в режиме безопасного выполнения имена в списке контрольной проверки, содержащие символы косой черты, игнорируются, и загружаются только общие объекты с включённым битом режима set-user-ID из стандартных каталогов поиска.

LD_BIND_NOT (начиная с glibc 2.1.95)

Если эта переменная окружения не равна пустой строке, то не обновлять GOT (global offset table — таблицу глобальных перемещений) и PLT (procedure linkage table — таблицу компоновки процедур) после определения символа функции. Совместное использовав эту переменную с LD_DEBUG (с категориями bindings и symbols), можно увидеть все привязки функции во время выполнения.

LD_DEBUG (начиная с glibc 2.1)

Выводить подробную отладочную информацию об операции динамического компоновщика. Содержимое этой переменной равно одной или нескольким следующим категориям, разделённым двоеточием, запятой или (если значение в кавычках) пробелом:

Начиная с glibc 2.3.4, LD_DEBUG игнорируется в режиме безопасного выполнения, если существует файл /etc/suid-debug (содержимое файла не важно).

LD_DEBUG_OUTPUT (начиная с glibc 2.1)

По умолчанию вывод LD_DEBUG записывается в стандартный поток ошибок. Если LD_DEBUG_OUTPUT определена, то вывод записывается в указанной значением файл с добавлением суффикса «.» (точка) ID процесса.

Переменная LD_DEBUG_OUTPUT игнорируется в режиме безопасного выполнения.

LD_DYNAMIC_WEAK (начиная с glibc 2.1.91)

По умолчанию при поиске общих библиотек для разрешения символьной ссылки динамический компоновщик будет использовать первое найденное.

В старых версией glibc (до 2.2) было другое поведение: если компоновщик определяет, что символ слабый, то он запоминает этот символ и продолжает поиск в оставшихся общих библиотеках. Если в последствии находится строгое определение того же символа, то он используется вместо запомненного (если больше символов не нашлось, то динамический компоновщик использует слабый символ, который был найден раньше).

Поведение старой glibc является нестандартным (стандартной практикой является учёт различия слабых и строгих символов только в момент статической компоновки). Текущее поведение динамического компоновщика появилось в glibc 2.2 (такое поведение предоставлялось в то время большинством других реализаций).

Создание переменной окружения LD_DYNAMIC_WEAK (с любым значением) включает старое (нестандартное) поведение glibc, тем самым, слабые символы одной общей библиотеки могут заменяться строгими символами, обнаруженными в другой библиотеке (заметим, что даже когда эта переменная установлена, строгие символы общей библиотеки не заменят слабые определения того же символа в основной программе).

Начиная с glibc 2.3.4, LD_DYNAMIC_WEAK игнорируется в режиме безопасного выполнения.

LD_HWCAP_MASK (начиная с glibc 2.1)

Маска для совместимости с аппаратными возможностями.

LD_ORIGIN_PATH (начиная с glibc 2.1)

Путь, где находится двоичный файл.

Начиная с glibc 2.4, LD_ORIGIN_PATH игнорируется в режиме безопасного выполнения.

LD_POINTER_GUARD (в glibc с 2.4 по 2.22)

Значение 0 отключает защиту указателя. Любое другое значение включает защиту указателя, что является действием по умолчанию. Защита указателя — это механизм безопасности, в результате которого некоторые указатели на код, хранящийся в перезаписываемой памяти программы (адреса возврата, сохраняемые setjmp(3) или указатели на функцию, используемые различными внутренними функциями glibc), искажаются полупроизвольным образом, что затрудняет атакующему подбор указателей для проведения атак переполнения буфера или срыва стека. Начиная с glibc 2.23, LD_POINTER_GUARD можно больше не использовать для отключения защиты указателя, так как теперь она всегда включена.

LD_PROFILE (начиная с glibc 2.1)

В переменной задаётся имя динамического объекта (одного) для профилирования, в виде пути или имени so. Результат профилирования записывается в файл с именем: «$LD_PROFILE_OUTPUT/$LD_PROFILE».

Начиная с glibc 2.2.5, LD_PROFILE игнорируется в режиме безопасного выполнения.

LD_PROFILE_OUTPUT (начиная с glibc 2.1)

Каталог, куда будет сохраняться результат работы с LD_PROFILE. Если эта переменная не определена или её значение равно пустой строке, то по умолчанию результат будет сохранён в каталог /var/tmp.

Переменная LD_PROFILE_OUTPUT игнорируется в режиме безопасного выполнения; вместо неё всегда используется /var/profile (это относится только к glibc до версии 2.2.5, так как в более новых версиях LD_PROFILE также игнорируется в режиме безопасного выполнения).

LD_SHOW_AUXV (начиная с glibc 2.1)

Если эта переменная окружения определена (с любым значением), то показывается вспомогательный массив, переданный из ядра (смотрите также getauxval(3)).

Начиная с glibc 2.3.4, LD_SHOW_AUXV игнорируется в режиме безопасного выполнения.

LD_TRACE_PRELINKING (начиная с glibc 2.4)

Если эта переменная окружения определена, то выполнять трассировку объекта предварительной компоновки, чьё имя указано в этой переменной окружения (для получения списка трассируемых объектов используйте ldd(1)). Если имя объекта не распознано, то трассируется все действия предварительной компоновки (prelinking activity).

LD_USE_LOAD_BIAS (начиная с glibc 2.3.3)

По умолчанию (т. е., если переменная не определена) исполняемые и предварительно скомпонованные объекты учитывают базовые адреса общих объектов, от которых они зависят, а (предварительно не скомпонованные) перемещаемые исполняемые (PIE) и другие общие объекты не учитывают их. Если переменной LD_USE_LOAD_BIAS присвоено значение 1, то и исполняемые файлы, и PIE учитывают базовые адреса. Если значение переменной LD_USE_LOAD_BIAS равно 0, то ни исполняемые файлы ни PIE не учитывают базовые адреса.

Начиная с glibc 2.3.3, данная переменная игнорируется в режиме безопасного выполнения.

LD_VERBOSE (начиная с glibc 2.1)

Если значение равно непустой строке, то выводится информация о символах программы (если также установлена переменная окружения LD_TRACE_LOADED_OBJECTS).

LD_WARN (начиная с glibc 2.1.3)

Если значение равно непустой строке, то выдаются предупреждения о ненайденных символах.

LD_PREFER_MAP_32BIT_EXEC (только для x86-64; начиная с glibc 2.23)

Согласно руководству по оптимизации ПО Intel Silvermont для 64-битных приложений, выполнение предсказания ветвления может отразиться негативным образом, если цель ветви находится дальше чем 4 ГБ от ветви. Если эта переменная окружения установлена (любое значение), то динамический компоновщик сначала попытается отобразить исполняемые страницы с помощью mmap(2) с флагом MAP_32BIT и, если это не удастся, то выполнит отображение без флага. Примечание: с флагом MAP_32BIT отображение выполняется в нижние 2 ГБ (не 4 ГБ) адресного пространства.

Так как при MAP_32BIT сокращается адресный диапазон, доступный для случайного выравнивания адресного пространства (ASLR), то LD_PREFER_MAP_32BIT_EXEC всегда отключается в режиме безопасного выполнения.

Аппаратные возможности¶

Некоторые общие объекты скомпилированы с использованием специальных аппаратных инструкций, которые существуют не в каждом ЦП. Такие объекты должны быть установлены в каталоги, чью имена (например, /usr/lib/sse2/) определяют требования к аппаратным возможностям. Динамический компоновщик проверяет эти каталоги учитывая аппаратуру машины и выбирает наиболее подходящую версию требуемого общего объекта. Каталоги аппаратных возможностей могут каскадироваться для объединения свойств ЦП. Список имён поддерживаемых аппаратных возможностей зависит от ЦП. В настоящее время распознаются следующие имена:

Alpha

ev4, ev5, ev56, ev6, ev67

MIPS

loongson2e, loongson2f, octeon, octeon2

PowerPC

4xxmac, altivec, arch_2_05, arch_2_06, booke, cellbe, dfp, efpdouble, efpsingle, fpu, ic_snoop, mmu, notb, pa6t, power4, power5, power5+, power6x, ppc32, ppc601, ppc64, smt, spe, ucache, vsx

SPARC

flush, muldiv, stbar, swap, ultra3, v9, v9v, v9v2

s390

dfp, eimm, esan3, etf3enh, g5, highgprs, hpage, ldisp, msa, stfle, z900, z990, z9-109, z10, zarch

x86 (только 32-битные)

acpi, apic, clflush, cmov, cx8, dts, fxsr, ht, i386, i486, i586, i686, mca, mmx, mtrr, pat, pbe, pge, pn, pse36, sep, ss, sse, sse2, tm