[devel] devel-static

Ср Авг 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>