[devel] devel-static
Andrey Savchenko
bircoph на altlinux.org
Ср Авг 25 22:14:38 MSK 2021
On Wed, 25 Aug 2021 20:14:41 +0300 Dmitry V. Levin wrote:
> On Wed, Aug 25, 2021 at 12:18:40PM +0300, Andrey Savchenko wrote:
> > On Wed, 25 Aug 2021 11:38:58 +0300 Vitaly Lipatov wrote:
> > > Ivan A. Melnikov писал 25.8.21 11:28:
[...]
> > > > Насколько boost-devel-static нужен именно при сборке пакетов в Сизиф
> > > > -- это другой вопрос. Я думаю, что скорее не нужен.
> > > Да. Я просто воспользовался случаем обратить внимание, что по
> > > возможности надо бы избавиться от статической линковки.
> >
> > А почему не наоборот?
> >
> > Динамическая линковка лишь создаёт иллюзию безопасности за счёт
> > исправления проблемы в одной библиотеке сразу для всех. Но проблема
> > может быть в хедерах, а C++ библиотеки всё больше переходят
> > в хедеры. В итоге может получится, что CVE исправлен, библиотека
> > обновлена без изменения ABI, а непересобранные приложения всё ещё
> > уязвимы.
>
> А безопаснее всего публиковать только исходники, и пусть пользователи
> сами пересобирают, как сочтут нужным, правда же?
На этот вопрос нельзя однозначно ответить, поскольку в таком
случае задача обеспечения безопасности во многом перекладывается на
пользователей и ответ зависит от их квалификации. Так вернёмся к
обсуждению DSO vs static в бинарном дистрибутиве общего назначения.
1) Безопасность.
Выше я привёл пример, когда DSO лишь маскирует проблему
безопасности, но не решает её. В случае со static очевидно, что
пересобирать нужно всех потребителей (при необходимости рекурсивно).
Так что относительно просто реализовать механизм контроля
гарантированного исправления ошибок и уязвимостей среди
прямых и косвенных пользователей библиотеки.
В случае с DSO может возникнуть крайне опасная ситуация скрытого
наличия уязвимости, когда CVE в библиотеке исправлен, по
setversions с клиентами всё хорошо, мы успешно заявили об
исправлении данной CVE в дистрибутиве, а в реальности уязвимость
кое-где осталась.
Самым простым решением данной проблемы будет безусловная пересборка
всех зависимостей, так же, как и со static — но в таком случае
никаких преимуществ у DSO не остаётся.
Можно попробовать отслеживать, были ли изменения хедеров
и пересобирать безусловно только в таком случае — но это более
сложный и в то же время всё ещё грубый путь решения задачи, т.к. не
всякое изменение в хедере ведёт к изменению бинарного кода
в клиенте.
Самым «изящным» решением будет аналог setversions для хедеров —
чтоб пересобирать только те зависимости, на которые влияют
выполненные изменения хедеров. Однако, мне такая задача
представляется не решаемой на практике без полной препроцессорной
обработки всех зависимостей, что по трудоёмкости сопоставимо с их
пересборкой.
2) Экономия памяти или места на диске.
Безусловно, для повсеместно используемых библиотек эффект будет
значимым — ну та же glibc. Однако, есть очень много библиотек для
одного-двух клиент и здесь выигрыша уже нет, а может быть
и проигрыш, т.к. DSO в общем случае приводит к менее эффективному
и более раздутому коду.
Это не только моё мнение, вот что пишет по этому поводу Линус
Торвальдс:
https://lore.kernel.org/lkml/CAHk-=whs8QZf3YnifdLv57+FhBi5_WeNTG1B-suOES=RcUSmQg@mail.gmail.com/
3) Производительность.
DSO в целом всегда хуже static. Иногда эта разница пренебрежима, во
многом это зависит от архитектуры (например, i686 здесь много хуже
amd64).
В любом случае, для более-менее хорошей производительности DSO
нужно сильно переписывать код по сравнению со static версией.
Совершенно невероятное по своей сложности руководство от Ульриха
Дреппера это подтверждает:
https://akkadia.org/drepper/dsohowto.pdf
Т.е. DSO можно сделать эффективной, но это неимоверное количество
работы, которую _обычно_ апстримы не делают в полной мере, или не
делают вовсе.
4) Технические сложности.
DSO характерны вечные проблемы версионирования, безопасности (relro
и now затем ведь делаются, м?), конфликтов по soname, технических
проблем (привер -fcommon) и т.п.. У static большинства этого нет.
Самое интересное, что даже Ульрих Дреппер призывает пореже
создавать DSO (и использовать PIE):
https://udrepper.livejournal.com/8790.html
В общем, тренд во многих дистрибутивах к выбросу static везде, где
только можно, мне представляется ошибочным. Разумеется, DSO тоже
нужны: как для широко используемых библиотек, так и для плагинов
и редких случаев, где без DSO работать не будет.
Так что я рекомендовал бы отказаться от подхода «а давайте выкинем
ещё и этот devel-static» и постепенно переходить к использованию
именно static версий в тех многих случаях, где они оправданы.
Best regards,
Andrew Savchenko
----------- следующая часть -----------
Было удалено вложение не в текстовом формате...
Имя : отсутствует
Тип : application/pgp-signature
Размер : 833 байтов
Описание: отсутствует
Url : <http://lists.altlinux.org/pipermail/devel/attachments/20210825/24ae34fc/attachment.bin>
Подробная информация о списке рассылки Devel