LINUX.ORG.RU

Статическая линковка

 , иди в свой двор,


0

2

Господа.

Вот на небезызвестном сайте cat-v.harmful.org утверждается:

Both performance and security are seriously harmed by dynamic linking

И если насчет performance можно поспорить*, то довод security мне совершенно непонятен. Ведь, если в библиотеке foz обнаружена серьезная уязвимость, то с динамической линковкой придется обновить только foz, а со статической — пересобрать все программы, использующие foz.

Может ли кто-нибудь объяснить, что имеется в виду?

Олсо, возможна ли статическая линковка всего в современном линуксе с количеством костылей, меньшим, чем в Gobolinux? (inb4 зачем? низачем. просто интересно.)

* хотя, несмотря на пример FreeBSD vs Plan9 в конце страницы по ссылке, в официальном FAQ Golang даже есть пункт:
Q: Почему у меня получаются такие большие бинарники?
A: Просто gc по умолчанию собирает их со статической линковкой.



Последнее исправление: rogvold (всего исправлений: 1)

Может имеется в виду то, что в инфраструктуре, основанной на свободном ПО, ничего не мешает перекомпилять программу с новой версией библиотеки, а статическая линковка исключает такие вещи, как подмена библиотеки враппером и перехват библиотечных функций.

kravich ★★★★
()

что имеется в виду?

Возможно, то, что очень много дырок было найдёно (и залатано) относящихся к библиотекам. Например, ты сделал mount -o noexec, а злоумышленник всё равно мог в старом libc вызывать программы через /lib/ld-linux.so.2 . Итд итп, много было дыр, в том числе с подменой окружения.

По тем же причинам можно считать злом suid-бинари. Впрочем, всё движется к тому чтобы обходится без этого флага.

true_admin ★★★★★
()

А если приедет апдейт foz с уязвимостями? Тогда уязвимыми станут сразу все программы, динамически с ней слинкованные.

Gobolinux

Там не статическая линковка. Там динамическая по принципу «всё своё ношу с собой».

В винде, помнится, некоторое время назад было былинное отверстие из-за того, что «.» находился в их аналоге ldpath.

PolarFox ★★★★★
()

Кстати, как в plan9 предлагается делать, например, плагины и подмену библиотечных функций? Короткое гугление ничего не дало кроме как «это возможно и без разделяемых библиотек».

true_admin ★★★★★
()
Ответ на: комментарий от PolarFox

что «.» находился в их аналоге ldpath.

А сейчас разве не так?

nanoolinux ★★★★
()
Ответ на: комментарий от rogvold

Зачем?!

Чтобы когда программа A работает с библиотекой X1.0, а B с библиотекой X1.1, их можно было безо всякого геморроя, присущего многим линуксам, поставить рядом.

PolarFox ★★★★★
()
Ответ на: комментарий от nanoolinux

не-обратносовместимые изменения в X
альтернативы - либо ломать совместимость, либо таскать тонны ненужного легаси, которое еще и ресурсы на поддержку жрет

marvin_yorke ★★★
()
Ответ на: комментарий от true_admin

плагины и подмену библиотечных функций

Просто, учитывая, что большинство вещей в плане реализуется через IPC, а не через магические библиотеки. Даже к http идёт обращение через webfs.

quantum-troll ★★★★★
()
Ответ на: комментарий от quantum-troll

большинство вещей в плане реализуется через IPC, а не через магические библиотеки

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

unsigned ★★★★
()
Ответ на: комментарий от unsigned

Украл мой комент. Плюсую вопрос про потерю перформанса.

nanoolinux ★★★★
()

то с динамической линковкой придется обновить только foz, а со статической — пересобрать все программы, использующие foz.

Ну зачем же мне все программы пересобирать (компилировать, что занимает львиную долю времени, и линковать), если их нужно только перелинковать. Поэтому-то гугл и работает над gold, быстрым линкером.

gag ★★★★★
()
Ответ на: комментарий от gag

их нужно только перелинковать

А так же нужно хранить полные сырцы всего со всем выхлопом компилера.

Лично я голосую за упрощение механизма библиотек, а не за искоренение его.

true_admin ★★★★★
()
Ответ на: комментарий от true_admin

Например, ты сделал mount -o noexec, а злоумышленник всё равно мог в старом libc вызывать программы через /lib/ld-linux.so.2

по-мойму это был баг в ядре

alex_custov ★★★★★
()
Ответ на: комментарий от true_admin

их нужно только перелинковать

А так же нужно хранить полные сырцы всего со всем выхлопом компилера.

Это правда. Но при использовании бинарного дистрибутива это перестаёт быть моей проблемой. И только для некоторых пакетов, которые я сам пересобираю, придётся хранить объектники. А ещё дистрибутивам нужно было бы наконец-то поголовно перейти на обновление пакетов через бинарные дифы!

Лично я голосую за упрощение механизма библиотек, а не за искоренение его.

Я тоже считаю, что решение дебиана перейти с одной библиотеки на другую для всех пакетов, которое и им тяжело даётся, - это ограничение моего права выбора с удобством(!) собирать свои проекты с другой версией этой библиотеки. Достаёт ситуация:

$ ls -l /usr/lib/libscalapack-openmpi.*
-rw-r--r-- 1 root root 10718896 Dec 29  2011 /usr/lib/libscalapack-openmpi.a
lrwxrwxrwx 1 root root       25 Dec 29  2011 /usr/lib/libscalapack-openmpi.so -> libscalapack-openmpi.so.1
lrwxrwxrwx 1 root root       29 Dec 29  2011 /usr/lib/libscalapack-openmpi.so.1 -> libscalapack-openmpi.so.1.8.0
-rw-r--r-- 1 root root  7079640 Dec 29  2011 /usr/lib/libscalapack-openmpi.so.1.8.0
$ 
В итоге толку от версии 1.8.0!?

Одним выходом является обсуждаемая статическая линковка. А вот есть ли серьёзные предложения, как довести до ума динамическую? Что делать в случае ошибочного поведения динамической либы, когда в проге пришлось применить обход этого дела, а после минорного(!), баг-фикс обновления либы прога перестала пахать? Явно нужны какие-то дополнительные конвенции и вот, точно, что-то в сторону интроспекции.

Тогда в примере с ошибочным поведением, можно было бы оформить баг-репорт, написать как правильную версию кода, так и с обходом. А решать, какую выполнять, каждый раз при старте программы, производя интроспекцию либы, которую подсунули в этот раз, в поисках тега баг «такой-то номер» исправлен. Вот только что-то нужно ещё добавить в процесс запуска: ведь мы не динамически подгружаем либу уже в рантайме (dlopen), а это выполняет ld-linux-....so за нас.

gag ★★★★★
()
Ответ на: комментарий от alex_custov

это был баг в ядре

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

true_admin ★★★★★
()
Ответ на: комментарий от nanoolinux

Расскажи это разработчикам микроядра.

рассказал разработчикам QNX. Они говорят что ты дебил.

anonymous
()
Ответ на: комментарий от gag

И только для некоторых пакетов, которые я сам пересобираю, придётся хранить объектники.

А разве не придётся хранить объектники для всех либ от которых зависят твои пакеты?

как довести до ума динамическую?

Да пролетают мысли как можно поменять. Я вот, например, хотел бы уйти от концепции размазывания пакетов по системе. Моё предложение: каждому пакету свою папку в которой была бы папка dependencies в которой есть симлинки на нужные версии пакетов. Это решает проблему наличия нескольких либ разных версий. Есть и другие варианты.

баг-фикс обновления либы прога перестала пахать

Это минус разрабам. Слышал, есть тулзы для проверки того что ABI не поменялся. По-моему, у qt такое видел.

true_admin ★★★★★
()
Ответ на: комментарий от gag

Да, отлично. А объектники ты хранишь в гите наверное?

nanoolinux ★★★★
()

Вообще это тема для толксов

со статической — пересобрать все программы, использующие foz.

В plan9 программ мало и они быстро пересобираются (нет ни boost, ни Qt, ни автошита), поэтому особой проблемы нет. С другой стороны, в динамически слинкованной системе добавляется «лишнее» звено — линкер — в котором могут быть уязвимости (в мохнатых годах они были и в линуксовом ld.so, сейчас — не в курсе, кто последним делал его аудит).

возможна ли статическая линковка всего

Нельзя собрать полностью статическую систему с современным glibc. Если без glibc, то можно попробовать, но определённый софт надо патчить, примерный объём патчей можно увидеть в репах того же alpinelinux.

x3al ★★★★★
()
Последнее исправление: x3al (всего исправлений: 2)
Ответ на: комментарий от anonymous

И при этом забывают, что у них при передаче сообщений нет авторизации. Хотя нет, они сами в этом признаються. Там, где про Neutrino-specific security issues.

Это я к тому, что их перформанс существует только лишь за счёт того, что выкинули всё «ненужное». Это как хсервер, без ssh. Или telnet с plaintext паролями в пакетах. А как только это понадобится, начнутся костыли, тормозящие всё на свете.

Видну с двумя одновременно работающими антивирусами видел? Вот будет что-то похожее.

nanoolinux ★★★★
()
Последнее исправление: nanoolinux (всего исправлений: 1)
Ответ на: комментарий от rogvold

О БОЖЕ
Зачем?!

Просто коллега чего-то попутал. Никто там не отказывался от внешних зависимостей, там отказались только от FHS. Or so I'm told.

proud_anon ★★★★★
()
Ответ на: комментарий от quantum-troll

а задержки на IPC далеко не всегда критичны.

Расскажи это разработчикам микроядра.

Задержки IPC важны, иначе в микроядре не пытались бы всё сделать хоть чуть-чуть быстрее десятилетиями.

Конечно, спору нет. Если у тебя IPC работает через езернет, оверхед на фоне задержек сети просто нивелируется, но допустим у тебя тупая задача передачи данных, от плагина в програму чем быстрее, тем лучше. Что ты будешь делать? Правильно, оптимизировать тот самый IPC.

Туповатый анонимус ляпнул, и даже не разобрался, за счёт чего ipc qnx быстр, как сискол. Хотя бы почитал что-нибудь по теме. Тот же «A Critique of the GNU Hurd Multi-server Operating...» там всё расписано, что и как, хороший обзор, хотя и не про qnx. Да и торвалдс уже устал объяснять: ipc это либо медленно, либо не-(или тяжело) портируемо/несекурно/обрезано по самое нехочу.

Но всё же, если говорить о plan9. Ты сам сказал, что авторизация там есть, следовательно есть оверхед. Я не берусь утверждать, т.к. про план действительно знаю мало, но мне не вериться, что ipc plan9 не менее эфективен, чем вызов библиотечной ф-ии из библиотеки.

nanoolinux ★★★★
()

Может ли кто-нибудь объяснить, что имеется в виду?

ИМХО имеется ввиду то, что враг может подменить либу.

Олсо, возможна ли статическая линковка всего в современном линуксе

почему нет? В слаке думаю можно попробовать. Другое дело, что это идиотизм ИМХО. Типа «что-бы не ходить в грязных вонючих носках, надо ходить без носков». В принципе всё верно, но в целом немного непонятно...

Почему у меня получаются такие большие бинарники?

они долго грузятся и жрут память. И обидно, что одно и то же грузить надо. /bin/false состоит из двух(ДВУХ!) строчек, но таки разворачивается в Over9000, из которых большинство — хидеры к либам. Что, из-за 20К кода, который ничего не делает, грузить кучу НЁХ?

drBatty ★★
()
Ответ на: комментарий от true_admin

Кстати, как в plan9 предлагается делать, например, плагины и подмену библиотечных функций? Короткое гугление ничего не дало кроме как «это возможно и без разделяемых библиотек».

будешь всё пересобирать, неужели непонятно?

drBatty ★★
()
Ответ на: комментарий от PolarFox

Чтобы когда программа A работает с библиотекой X1.0, а B с библиотекой X1.1, их можно было безо всякого геморроя, присущего многим линуксам, поставить рядом.

и естественно это нужно делать по умолчанию! А то как же юзер будет второй IE ставить-то???

drBatty ★★
()
Ответ на: комментарий от nanoolinux

Назови причины, почему А не может работать с Х1.1?

потому-что ошибка в коде ДНК.

drBatty ★★
()
Ответ на: комментарий от gag

если их нужно только перелинковать

ага «только». Только перелинковать нужно только программисту, который над этим работает. Ибо все остальные не станут хранить тонны временного мусора между релизами. И придётся их собирать с нуля.

drBatty ★★
()
Ответ на: комментарий от quantum-troll

Безопасность таки выше

эффект неуловимого Джо в квадрате. Понимаю.

а задержки на IPC далеко не всегда критичны.

IPC

это такое заклятья оттуда?

drBatty ★★
()
Последнее исправление: drBatty (всего исправлений: 1)
Ответ на: комментарий от gag

А ещё дистрибутивам нужно было бы наконец-то поголовно перейти на обновление пакетов через бинарные дифы!

там профит минимален. Иной раз новый пакет весит меньше, чем дифф.

В итоге толку от версии 1.8.0!?

кто плакал, что хочет две версии сразу? Получи. Одна прога одно хочет, а другая другое. ПМ ставит обе.

drBatty ★★
()
Ответ на: комментарий от true_admin

Моё предложение: каждому пакету свою папку в которой была бы папка dependencies в которой есть симлинки на нужные версии пакетов. Это решает проблему наличия нескольких либ разных версий.

а мамку каждому?!

drBatty ★★
()
Ответ на: Вообще это тема для толксов от x3al

В plan9 программ мало и они быстро пересобираются (нет ни boost, ни Qt, ни автошита)

ну и нах оно нужно?

С другой стороны, в динамически слинкованной системе добавляется «лишнее» звено — линкер

ну да, а в статических нет?

Нельзя собрать полностью статическую систему с современным glibc.

что именно мешает, кроме упоротости?

drBatty ★★
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.