Explains: Linux linux-gate.so.1 Library / Dynamic Shared Object [ vdso ]
I ‘m using the ldd command to get information about /usr/local/nginx/sbin/nginx binary and I see linux-gate.so.1 library. However, I’m unable to find out this file anywhere on the system? What is linux-gate.so.1 and how do I copy this file?
linux-gate.so.1 is nothing but the Linux Virtual Dynamic Shared Object. This file only exists in each executables address space. In other words you don’t have to copy or worry about this file as it is a virtual library. According to this article:
This virtual library provides the necessary logic to allow user programs to access system functions through the fastest means available on the particular processor, either interrupt, or with most newer processors, fast system call.
This VDSO exposed by the kernel at a fixed address in every process’ memory:
cat /proc/self/maps
Sample outputs:
- No ads and tracking
- In-depth guides for developers and sysadmins at Opensourceflare✨
- Join my Patreon to support independent content creators and start reading latest guides:
- How to set up Redis sentinel cluster on Ubuntu or Debian Linux
- How To Set Up SSH Keys With YubiKey as two-factor authentication (U2F/FIDO2)
- How to set up Mariadb Galera cluster on Ubuntu or Debian Linux
- A podman tutorial for beginners – part I (run Linux containers without Docker and in daemonless mode)
- How to protect Linux against rogue USB devices using USBGuard
Join Patreon ➔
See this blog post which explains linux-gate.so.1 vdso in the details.
🐧 Get the latest tutorials on Linux, Open Source & DevOps via
Источник
Программы и библиотеки Linux
Процессы операционной системы в большинстве случаев отождествляются с выполняющимися программами, что не совсем верно, точнее — совсем не верно. В современных операционных системах, включая Linux, между программой и процессом есть очевидная взаимосвязь, но далеко не такая непосредственная, как кажется на первый взгляд.
Программа представляет собой алгоритм, записанный на определенном языке, понятном исполнителю программы (программа политической партии и программа научной конференции имеют тот же смысл, что и компьютерная программа, но предназначены для других исполнителей).
Различают машинный язык, понятный центральному процессору, и языки более высоких уровней (алгоритмические), понятные составителю программы — программисту.
Программы, составленные на языке высокого уровня, в любом случае перед исполнением должны быть транслированы (переведены) на язык исполнителя, что реализуется при помощи специальных средств — трансляторов.
Различают два вида трансляторов программ — компиляторы и интерпретаторы. Компилятор транслирует в машинный код сразу всю программу целиком и не участвует в ее исполнении. Интерпретатор, наоборот, пошагово транслирует отдельные инструкции программы и немедленно выполняет их.
Например, командный интерпретатор при интерактивном режиме пошагово, выполняет команды, вводимые пользователем, а в пакетном режиме так же пошагово выполняет команды, записанные в файле сценария.
Алгоритм, в свою очередь, есть некоторый набор инструкций, выполнение которых приводит к решению некоторой задачи.
В большинстве случаев, инструкции алгоритма имеют причинно-следственные зависимости и выполняются исполнителем последовательно. Однако если выделить «независимые» поднаборы инструкций (независимые ветви), то их можно выполнять несколькими исполнителями одновременно — параллельно.
Поэтому различают последовательные и параллельные алгоритмы и соответствующие им последовательные и параллельные программы.
Некоторые программы реализуют алгоритмы общего назначения, например алгоритмы сжатия или шифрования информации, алгоритмы сетевых протоколов и т. д. Такие программы, востребованные не столько конечными пользователями, сколько другими программами, называют библиотеками.
Согласно hier, откомпилированные до машинного языка программы размещаются в каталогах /bin, /sbin, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, а библиотеки — в каталогах /lib, /usr/lib, /usr/local/lib.
Программы имеют специальный бинарный «запускаемый» формат W:[ELF] executable и зависят от библиотек, что проиллюстрировано в листинге ниже при помощи команды ldd (loader dependencies). Каждая зависимость отображается именем библиотеки (SONAME, shared object name), Найденным в системе файлом библиотеки и адресом (для противодействия эксплуатации уязвимости в программах адрес выбирается случайным образом, см. W:[ASLR]). в памяти процесса (32- или 48-битным, в зависимости от платформы), куда библиотека будет загружена.
Программы и библиотеки
$ which ls
$ file /bin/ls
/bin/ls: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs), for GNU/Linux 2.6.24, BuildID[shal]=0x83531f308flfal8221be53eaf399303400cl4638, stripped
$ ldd /bin/ls
libselinux.so.l => /lib/i386-linux-gnu/libselinux.so.1 (0xb7708000) librt.so.l => /lib/i386-linux-gnu/librt.so.l (0xb76ff000) libacl.so.l => /lib/i386-linux-gnu/libacl.so.l (0xb76f5000)
libc.so.6 => /lib/1386-linux-gnu/libc. so.6 (0xb754b000)
libdl.so,.2 => /lib/i386- linux — gnu/libdl. so. 2 (0xb7546000)
libpthread.so.0 => /lib/i386-linux-gnu/libpthread.so.0 (0xb752b000) libattr.so.l => /lib/i386-linux-gnu/libattr.so.l (0xb7525000)
$ file lib/i386-linux-gnu/libc.so.6
/lib/i386-linux-gnu/libc.so.6: symbolic link to ‘libc-2.15.so’
Нужно заметить, что файла библиотеки linux-gate.so.1 (реализующей интерфейс системных вызовов к ядру) не существует, т. к. она является виртуальной (VDSO, virtual dynamic shared object), т. e. предоставляется и отображается в память процесса самим ядром, «как будто» является настоящей библиотекой.
Кроме того, библиотека ld-llnux.so.2 указана абсолютным путевым именем, поэтому поиск ее файла не производится.
Для большинства библиотек зависимость устанавливается при помощи SONAME вида libNAME.so.x где lib — стандартный префикс (библиотека), .so — суффикс (разделяемый объект), NAME — имя «собственное», а .X — номер версии ее интерфейса. По имени SONAME в определенных (конфигурацией компоновщика — ld.so и ldconfig) каталогах производится поиск одноименного файла библиотеки, который на самом деле оказывается символической ссылкой на «настоящий» файл библиотеки.
Например, для 6-й версии интерфейса динамической библиотеки языка с (libc.so.6) настоящий файл библиотеки называется libc-2.15.so, что указывает на версию самой библиотеки как 2.15.
Версии библиотек
$ file /lib/1386-linux-gnu/libacl.so. 1
/lib/1386-linux-gnu/libacl.so.1: symbolic link to ‘libacl.so.1.1.0’
Аналогично, в листинге выше показано, что для 1-й версии интерфейса динамической библиотеки списков контроля доступа acl (libacl.so. 1) настоящий файл библиотеки называется libacl.so.1.1.0, а это указывает на версию самой библиотеки как 1.1.0.
Такой подход позволяет заменять (исправлять ошибки, исправлять неэффективные алгоритмы и пр.) библиотеки (при условии неизменности их интерфейсов) отдельно от программ, зависящих от них.
При обновлении библиотеки libc-2.15.so, например, до libc-2.i8.so достаточно установить символическую SONAME-ссылку libc.so.6 на libc-2.18.so, в результате чего ее начнут использовать все программы с зависимостями от libc.so.6.
Более того, в системе может быть одновременно установлено любое количество версий одной и той же библиотеки, реализующих одинаковые или разные версии интерфейсов, выбор которых будет указан соответствующими SONAME-ссылками.
Библиотеки- это незапускаемые программы
$ file /lib/i386-linux-gnu/libc-2.15.so
/lib/i386-linux-gnu/libc-2.15.so: ELF 32-bit LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked (uses shared libs),
BuildID[shal]=0x87bb99bc34Ofl345950611a3d9cfeclcb49532dc, for GNU/Linux 2.6.24, stripped
$: file /llb/i386-linux-gnu/libacl.so.1.1.0
/llb/1386-llnux-gnu/llbacl.so.1.1.0: ELF 32-blt LSB shared object, Intel 80386, version 1 (SYSV), dynamically linked, BulldID[shal]=0xd48c066c7c7deba7c88505fe434d4601e3e91f50, stripped
$: ldd /llb/l386-llnux-gnu/llbacl.so.1.1.0
libattr.so.l => /lib/1386-linux-gnu/llbattr.so.1 (0xb76ca000)
libc.so.6 => /lib/i386-ltnux-gnu/libc.so.6 (0xb7520000)
Библиотеки имеют тот же бинарный формат W:[ELF], что и «запускаемые» программы, но не «запускаемый» executable, а «совместно используемый» shared object.
Библиотеки, являясь пусть и незапускаемыми, но программами, естественным образом тоже зависят от Других библиотек, что показано в листинге выше.
Практически, «запускаемость» ELF-файлов зависит не от их типа, а от прав доступа и осмысленности точки входа адреса первой инструкции, которой передается управление при попытке, запуска. Например, библиотеку libc-2.15.so можно запустить, в результате чего будет выведена статусная информация.
Запускаемые библиотеки
$ Is -l lib/l386-linux-gnu/libc-2.15.so
-rwxr-xr-x 1 root root 1730024 окт. 6 2018 /lib/i386-linux-gnu/libc-2.15.so
$ lib/l386-linux-gnu/libc-2.15.so
GNU C Library (Ubuntu EGLIBC 2.15-0ubuntu10.3) stable release version 2.15, by Roland McGrath et al.
crypt add-on version 2.1 by Michael Glad and others GNU Libidn by Simon Josefsson
★ Native POSIX Threads Library by Ulrich Drepper et al
Выполняющиеся программы являются основными активными сущностями, инструкции которых при помощи механизма системных вызовов потребляют ресурсы, находящиеся под управлением операционной системы. Распределением этих ресурсов и занимаются подсистемы управления процессами, управления памятью и ввода-вывода, в достаточно детальной мере рассмотренные в этой главе.
Основной задачей этих подсистем является организация эффективного распределения ресурсов между массой их потребителей — процессами и нитями.
Фактическая эффективность их работы при прочих равных будет во многом зависеть от понимания пользователем их внутренних алгоритмов и значений конфигурационных параметров этих алгоритмов, в зависимости от характеристик самих потребителей и желаемых результатов. Например, эффективность распределения процессорного времени будет напрямую зависеть от свойств процессов и нитей, их приоритетов, их классов и процессорных привязок.
Кроме того, понимание алгоритмов работы подсистем может ответить на многие вопросы о количестве потребляемых ресурсов и дать ответ об их достаточности или недостатке. Например, важно понимать, что недостаток ресурса оперативной памяти вовсе не определяется суммарными размерами виртуальной памяти, потребленной процессами, а напрямую связан с суммарными размерами их резидентной памяти.
Навыки мониторинга и трассировки потребления ресурсов процессами помогут сделать массу полезнейших выводов о свойствах выполняющихся в них программ, что чрезвычайно полезно при разработке качественного программного обеспечения.
Не лишними эти навыки будут и при выборе качественного программного обеспечения для эксплуатации в заданных условиях и с требуемыми характеристиками.
Источник
[Ubuntu] Зависимости исполняемого файла
Я слышал, что есть такая чудо-утилита под названием ldd, которая показывает, от каких dll-ок зависит мой исполняемый файл. Прогнал своё поделие через неё, и она мне выдал кучу библиотек, многие из которых имеют ничего мне не говорящие имена (откуда они там взялись — одному Богу известно)
Как мне по этой информации узнать, от каких deb пакетов зависит моя программа? одним словом, чё мне писать в графе Depends при использование checkinstall?
Эмм. А какие инклуды то хоть?
dpkg -S имя файла
Ты что, не знаешь какие библиотеки ты использовал? Наверняка в dpkg есть функци чтобы посмотреть какому пакету принадлежит файл.
И что с этим делать?
он мне предлагает libssl0.9.8, но я не хочу привязываться к конкретной версии ssl
Мне нужен универсальный метод быстро получить зависимости, типа:
а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль, и не дрожать от мысли о том, что программа не запустится из-за того, что на компе клиента нет какой-то маленькой неприметной библиотечки
Use debhelper, Luke!
>а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль, и не дрожать от мысли о том, что программа не запустится из-за того, что на компе клиента нет какой-то маленькой неприметной библиотечки
тонко
man apt-file
ТС, ты тот еще тормоз, к примеру, показывает мой хеллоуворд зависимость libc.so.6, в зависимости значит нужно пихать glibc, как то так.
> а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль
это не линукс-вэй =) Здесь нужно вначале сделать тучу бесполезных времязатратных телодвижений, т.е. заняться сексом
но я не хочу привязываться к конкретной версии ssl
посмотри, какие симлинки есть на libcrypto.so.0.9.8, мб просветлит..
хотя в случае libssl, возможно, есть смысл привязываться к конкретной версии. А то при ее обновлениях универсальные проги мрут как мухи)
пока мантейнеры пакетов в кровавых битвах еще не до конца выяснили, чей пакет главнее, и что куда класть, не будет тебе такой утилиты )
резюме: предлагаю попросить в этом деле помощи у Бога лично
> Мне нужен универсальный метод быстро получить зависимости, типа:
Просто феерическая наглость.
Даю хинт. Этот универсальный метод называется «нанять человека, который разбирается в устройстве юникс и решит эту задачу за тебя».
а не сидеть часами и выяснять, к какому пакету относится тот или иной модуль, и не дрожать от мысли о том, что программа не запустится из-за того, что на компе клиента нет какой-то маленькой неприметной библиотечки
Ты не знаешь, какие библиотеки использует код, который ты сам писал? Похвально, весьма похвально.
> Просто феерическая наглость.
Ты не знаешь, какие библиотеки использует код, который ты сам писал?
жир залил весь монитор! как ты научился писать столь калорийные посты?
Источник
