From: Andrey Savchenko <bircoph@altlinux.org>
To: ALT Linux Team development discussions <devel@lists.altlinux.org>
Subject: Re: [devel] devel-static
Date: Wed, 25 Aug 2021 22:14:38 +0300
Message-ID: <20210825221438.251ee68ab82331f0ee59702f@altlinux.org> (raw)
In-Reply-To: <20210825171440.GA22230@altlinux.org>
[-- Attachment #1: Type: text/plain, Size: 7832 bytes --]
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
[-- Attachment #2: Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2021-08-25 19:14 UTC|newest]
Thread overview: 75+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-08-24 18:20 [devel] I: LTO in %optflags by default Dmitry V. Levin
2021-08-24 18:21 ` Dmitry V. Levin
2021-08-24 18:22 ` Dmitry V. Levin
2021-08-25 0:04 ` Dmitry V. Levin
2021-08-25 8:18 ` Vitaly Lipatov
2021-08-25 8:28 ` Ivan A. Melnikov
2021-08-25 8:38 ` Vitaly Lipatov
2021-08-25 9:18 ` Andrey Savchenko
2021-08-25 17:14 ` [devel] devel-static Dmitry V. Levin
2021-08-25 17:25 ` Alexey Sheplyakov
2021-08-25 19:19 ` Andrey Savchenko
2021-08-25 19:14 ` Andrey Savchenko [this message]
2021-08-25 19:58 ` Vitaly Lipatov
2021-08-25 20:52 ` Andrey Savchenko
2021-08-25 21:06 ` Vitaly Lipatov
2021-08-25 21:36 ` Andrey Savchenko
2021-08-27 19:43 ` [devel] Статические библиотеки и thin LTO (Was: I: LTO in %optflags by default) Alexey Sheplyakov
2021-08-27 22:18 ` [devel] Статические библиотеки и thin LTO Vitaly Chikunov
2021-08-29 6:34 ` Alexey Sheplyakov
2021-08-30 9:18 ` Dmitry V. Levin
2021-08-30 9:30 ` Andrey Savchenko
2021-08-30 9:39 ` Dmitry V. Levin
2021-08-30 14:36 ` Andrey Savchenko
2021-08-30 9:50 ` Arseny Maslennikov
2021-08-24 18:23 ` [devel] I: LTO in %optflags by default Dmitry V. Levin
2021-08-24 19:19 ` Dmitry V. Levin
2021-08-25 0:33 ` Dmitry V. Levin
2021-08-26 6:00 ` [devel] I: LTO in %optflags by defaulta (top-level asm) Vitaly Chikunov
2021-08-25 5:27 ` [devel] I: LTO in %optflags by default Ivan A. Melnikov
2021-08-25 5:46 ` Denis Medvedev
2021-08-25 5:50 ` Denis Medvedev
2021-08-25 6:53 ` Andrey Savchenko
2021-08-25 7:03 ` Denis Medvedev
2021-08-25 7:32 ` Andrey Savchenko
2021-08-26 18:43 ` Michael Shigorin
2021-08-25 7:12 ` Ivan A. Melnikov
2021-08-25 8:14 ` Alexey Tourbin
2021-08-25 8:39 ` Andrey Savchenko
2021-08-25 7:12 ` Alexey Sheplyakov
2021-08-25 16:28 ` Dmitry V. Levin
2021-08-25 17:48 ` Dmitry V. Levin
2021-08-25 7:37 ` Alexey Sheplyakov
2021-08-25 18:07 ` [devel] Administrivia Dmitry V. Levin
2021-08-25 19:25 ` Alexey Sheplyakov
2021-08-25 20:03 ` Alexey V. Vissarionov
2021-08-26 19:02 ` [devel] Administrivii Michael Shigorin
2021-08-26 19:18 ` [devel] debugedit Dmitry V. Levin
2021-10-13 9:16 ` [devel] debugedit DWARF version 0 Denis Medvedev
2021-10-13 9:51 ` Dmitry V. Levin
2021-10-13 9:51 ` Denis Medvedev
2021-08-25 19:27 ` [devel] I: LTO in %optflags by default Andrey Savchenko
2021-08-25 23:54 ` Dmitry V. Levin
2021-08-26 9:35 ` Alexey V. Vissarionov
2021-08-26 19:33 ` Andrey Savchenko
2021-08-27 0:37 ` Dmitry V. Levin
2021-08-27 8:07 ` Sergey V Turchin
2021-08-27 9:11 ` Alexey V. Vissarionov
2021-08-27 10:00 ` Alexey Sheplyakov
2021-08-27 12:54 ` Dmitry V. Levin
2021-08-25 10:45 ` Vitaly Lipatov
2021-08-25 16:20 ` Dmitry V. Levin
2021-08-25 20:23 ` Vitaly Lipatov
2021-08-25 20:30 ` Dmitry V. Levin
2021-08-25 21:24 ` Dmitry V. Levin
2021-08-25 23:07 ` Aleksey Novodvorsky
2021-08-25 23:19 ` Dmitry V. Levin
2021-08-25 23:54 ` Andrey Savchenko
2021-08-26 0:04 ` Dmitry V. Levin
2021-08-26 6:39 ` Andrey Savchenko
2021-08-26 7:25 ` Vitaly Lipatov
2021-08-27 0:20 ` Dmitry V. Levin
2021-08-26 9:40 ` Alexey V. Vissarionov
2021-08-26 4:23 ` alexei
2021-08-26 8:24 ` Dmitry V. Levin
2021-08-26 0:26 ` Dmitry V. Levin
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20210825221438.251ee68ab82331f0ee59702f@altlinux.org \
--to=bircoph@altlinux.org \
--cc=devel@lists.altlinux.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
ALT Linux Team development discussions
This inbox may be cloned and mirrored by anyone:
git clone --mirror http://lore.altlinux.org/devel/0 devel/git/0.git
# If you have public-inbox 1.1+ installed, you may
# initialize and index your mirror using the following commands:
public-inbox-init -V2 devel devel/ http://lore.altlinux.org/devel \
devel@altlinux.org devel@altlinux.ru devel@lists.altlinux.org devel@lists.altlinux.ru devel@linux.iplabs.ru mandrake-russian@linuxteam.iplabs.ru sisyphus@linuxteam.iplabs.ru
public-inbox-index devel
Example config snippet for mirrors.
Newsgroup available over NNTP:
nntp://lore.altlinux.org/org.altlinux.lists.devel
AGPL code for this site: git clone https://public-inbox.org/public-inbox.git