#cargo #rust

Cargo довольно сильно сопротивляется патчингу исходников.

Натуральный способ патчинга в случае сборки с cargo - это завендорить все исходники, и, перед сборкой, запатчить завендоренное.

Есть вот такой вот тикет https://github.com/rust-lang/cargo/issues/11063 (полагаю, не единственный), там обсуждаются разные всратые решения этой проблемы.

Понятное дело, что #errogant upstream на хую вертел downstream, потому что "собирайтесь как автор кода захотел левой пяткой", а проблемы негров (конкретно, людей, которым нужно собираться в разных необычных окружениях, типа моего) их не волнуют.

Я потырил решение у IBM RedHat сообщества федоры - https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec#_615, им, сюрприз-сюрприз, тоже хочется уметь развендоренные исходники, чего бы там себе не воображали школота зумеры разработчики на Rust. Потому что баги в libz/libgit2/openssl патчить им, а не тем, кто принудительно завендорил исходники, без возможности сборки с системным вариантом.

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

Развендориваю я их довольно грубо - сначала ищу все крейты в которых есть c/c++ файлы (https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/classify.py), потом "обнуляю" сборку этих крейтов (https://github.com/pg83/ix/blob/main/pkgs/bld/rust/devendor/scripts/devendor.sh#L14-L17) Федора развендоривает какие-то заранее известные крейты - https://src.fedoraproject.org/rpms/rust//blob/rawhide/f/rust.spec#_585

Я тут обнаружил, что, при вендоринге почти любой растопрограммы, ко мне приезжает куча .a файлов.

Вот, неполный список, https://gist.github.com/pg83/a784999d767da8924fea3f28b5517372, мне было лень его фильтровать и копипастить целиком.

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

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

Почему, когда человек кладет 1 бинарную программу, на него ополчается все продвинутое растосообщество, а когда, вот так вот, приезжает пара сотен мегабайт бинарных блобов, то всем похуй?

У меня, конечно, есть гипотезы, но они совершенно не в пользу растового community.

sr.ht, кстати, починили.

А я, кстати, хочу сказать, что, благодаря нашим анонимным благожелателям, пользователи #stal/ix этого даже не заметили, благодаря нашей мощной системе зеркал, которых ажно уже 9 штук!

https://t.iss.one/itpgchannel/1371
https://github.com/pg83/ix/blob/main/pkgs/die/scripts/mirrors.txt

Вот, реально, все это время, пока лежал sr.ht, сборка шла с кешей на зеркалах, такие дела.

Если вспомните, то раньше, в такие моменты я всегда ругался на очередной васянский gitlab, а тут даже и не ругался, потому что все прошло очень даже хорошо.

https://t.iss.one/itpgchannel/1342
https://t.iss.one/itpgchannel/1300
https://t.iss.one/itpgchannel/1085

#rust, bloat #gold

Несколько лет назад, когда я смотрел на rust, мне очень импонировал тот факт, что бинарники с программами на rust были весьма компактны.

Типа, единицы мегабайт, даже для довольно сложных программ.

Сейчас это, к сожалению, уже не так.

Десятки, и даже сотни, мегабайт!

(я не буду тут приводить никаких конкретных цифр и статистик, потому что время и формат канала не позволяет)

Почему так происходит?

Я это связываю с ростом code bloat, со временем.

Что такое code bloat?

Я не знаю, как определить это формально, неформально скажу так - code bloat случается, когда библиотеки начинают в себе содержать те или иные "фабрики" по производству объектов:

if (arg == "x") {return new X(...);}
if (arg == "y") {return new Y(...);}
...

(это, понятное дело, модельный пример, основной признак фабрики - это когда мы связываем какой-то широкий набор функциональности с пользовательским вводом)

Такие фабрики плохи тем, что линкер, даже с LTO, не может выкинуть из программы неиспользуемый код, потому что просто не может доказать, что тот или иной if не случается в runtime.

Благодаря этому, несмотря на то, что код вашей программы растет линейно по времени (при условии неизменности ваших усилий со временем), объем слинкованного (и скомпилированного) кода растет существенно быстрее. В пределе, "что скомпилировали, то и влинковали".

Причем как это - "существенно быстрее", само по себе, очень интересный вопрос.

Чтобы хорошо на него ответить, нужно уметь моделировать реалистичные графы зависимостей большого объема софта, уметь моделировать их развитие со временем, и после этого запустить на этой модели какую-нибудь симуляцию.

Я таких исследований не встречал, если вы что-то видели или знаете, покажите.

Я умею себя убеждать, что code bloat растет примерно как X(t)^depth(dependency tree), где X - примерно линейная функция от времени, с небольшой константой у линейной части. Повторюсь, это верно при линейном росте кода вашего проекта, и при условии, что глубина дерева зависимостей на рассматриваемом участке времени не меняется сильно.

Еще важными факторами в rust является:

* Социальный аспект. Разработчики считают, что код на rust "безопасный", поэтому новые зависимости не страшны. Это сильно отличается от мира C/C++, где каждая новая зависимость - это потенциальные сегфолты, и ну ее в жопу, лучше написать велосипед по месту. Go тут стоит где-то посредине между C/C++ и Rust.

* Отличие модульной системы go и rust, я писал про это в https://t.iss.one/itpgchannel/1155. Вот из ссылки из того моего текста довольно таки очевидно следует, что число зависимостей типового расторепозитория будет выше, чем в go. В C/C++ вообще нет модульной системы и пакетного менеджера, поэтому в ней число зависимостей типового проекта еще меньше (*).

Пока я на вас вывалил некоторое количество моделей, моих предположений про экосистемы, и так далее.

А выводы-то?

Медленнее всего толстеют со временем C/C++ программы, потом программы на Go, а чемпион по росту - rust. Да, да, ваш любимый rust - чемпион по code bloat (на данный момент). По крайней мере, я это весьма четко вижу по размерам бинарников в моей системе. Причем рост этот существенно более быстрый, чем линейный.

А что будет лет через 10, если этот процесс не остановится, я вообще боюсь себе представить!

(*) в больших монорепах, где много тестов и зависимость сделать еще проще, чем в cargo, С/С++ программы растут примерно так же быстро, как rust в open source, и многие из нас знают, что это значит для размера получающихся бинарников.

#execline

Забавно, оказывается, примерно год назад, то есть, через год после нашего с ним спора (https://github.com/skarnet/execline/issues/9 https://t.iss.one/itpgchannel/216), чувак таки запилил busybox/multicall binary - https://github.com/skarnet/execline/commit/edf81b0d16322e5d49ec22f394b669d9094daac1

Как он это аргументировал?

"The multicall setup saves a lot of disk space, at the price of an unnoticeable amount of CPU usage. RAM usage is about equivalent and difficult to assess. The setup is meant for embedded devices or small distributions with a focus on saving disk space"

https://skarnet.org/software/execline/execline.html

"I am not a fan of multicall binaries at all.

However, it just so happens that the execline package already was a good candidate for a multicall configuration, and several users had been asking for it (and complaining about the amount of disk space that the traditional execline package uses). So I did an experiment, and it turned out that a multicall execline binary does save a huge amount of space. Depending on your shared/static library configuration and your libc, the gain in disk space on Linux can range from 66% to 87%! The results were contrary to my expectations — and simply too good to pass up"

Да примерно так же, как и я.

Пришел ли он в тот тикетос, где мы с ним это обсуждали, и сказал: "дорогой PG, ты, как обычно, во всем был прав, на, используй!"?

Вопрос, конечно, риторический.

Пакет, после того, как я включил эту фичу, стал занимать 250к вместо 20MB.

Перечитал текст, и понял, что мое определение вполне удобно формализуемо.

code bloat - это код, слинкованный в приложение, который не имеет шанса быть запущенным ни при каких пользовательских данных.

Можно еще считать сколько кода было скомпилировано в .o файлы, но не попало в слинкованное приложение, но это менее интересная метрика.

Будни #bootstrap

А я запустил chromium.

Собрать не собрал, но запустил. Скорее, для удовлетворения любопытства - "а как можно наиболее дешево запустить chromium (или похожее приложение) на статически слинкованной системе, срезав как можно больше углов"?

Первым делом я решил попробовать сборку AppImage - https://ungoogled-software.github.io/ungoogled-chromium-binaries/releases/appimage/64bit/120.0.6099.129-1

Идейно #AppImage - очень классная штука, я бы назвал ее flatpak/snap здорового человека. Здорового, потому что, в отличие от вышеуказанных технологий, appimage не решает задачу vendor lock на конкретную технологию.

Поэтому он сделан максимально тупо. Это небольшой runtime, который конкатенируется с squashfs образом:

mksquashfs Your.AppDir Your.squashfs \
    -root-owned -noappend
cat runtime >> Your.AppImage
cat Your.squashfs >> Your.AppImage
chmod a+x Your.AppImage

При запуске этого файла, runtime находит смещение образа, монтирует его через squashfs-fuse, и запускает из него скрипт AppRun, который делает всю магию (например, делает LD_LIBRARY_PATH в нужные пути, или даже делает bind mount, чтобы еще лучше обмануть оборачиваемое приложение).

Простая, примитивная, штука, которая не пытается быть всеобъемлющим рантаймом (потому что не решает задачу привязать пользователя к экосистеме).

Проблема в том, что умолчальный рантайм зависит от glibc, а сборка от ungoogled вообще не тащит никакие библиотеки с собой, то есть, их appimage - fake.

Но я не отчаялся, и вспомнил про https://github.com/Kron4ek/Conty

Это такой "appimage наоборот" - типа, давайте не ждать, что пользователь положит в squashfs все нужные библиотеки, а просто сделаем то же самое, что делает appimage, но подложим туда смерть смерть кладбище "весь Arch". Ну вот там, реально, в squashfs лежит весь Arch - несколько гигабайт бинарного говна: https://github.com/Kron4ek/Conty/releases/tag/1.25 (посмотрите на размеры)

А дальше происходит все то же самое, что делает AppImage, только дополнительным образом идет слой библиотек и программ из Arch.

Дальше запустить распотрошенный appimage с ungoogled chromium довольно просто:

# unshare -U -r -m
# ALLOW_ROOT=1 ./conty_lite.sh \
    ./Downloads/squashfs-root/AppRun \
    --no-sandbox  \
    --ozone-platform=wayland

Тут "трюк" в первой строке - мы переходим в новый user namespace, где у нас uid 0, и потому сможет сработать squashfs fuse, а без этого надо делать fusermount suid bit (чего мне очень не хочется).

Понятное дело, что это не prod ready, но для хохмы сойдет.

Кстати, распотрошил я исходный appimage довольно "изящно" - так как мы не знаем offset, с которого начинается squashfs, то попробуем все, от 0, до бесконечности, пока не получится распаковать:

import sys
import subprocess as sp

# 193728
def unsq(f):
    for i in range(0, 10000000):
        try:
            print(i)
            cmd = [
                'unsquashfs', 
                '-o', 
                str(i), 
                f
            ]
            return sp.check_call(cmd)
        except Exception as e:
            pass

unsq(sys.argv[1])

Вышел curl 8.6.0

Проблема с ним в том, что он, эм, не собирается:

https://github.com/curl/curl/blob/master/lib/curl_ntlm_wb.c#L269

usigned char buf[1024]

Найдите 2 ошибки, хехе.

Вот что значит не прогонять релизы через нормальный CI.

И это, простите, библиотека, на которой держится половина этих ваших интернетов.

https://www.openwall.com/lists/oss-security/2024/01/30/6

https://www.opennet.ru/opennews/art.shtml?num=60528

https://lobste.rs/s/xydlkq/new_linux_glibc_flaw_lets_attackers_get

Вот, пожалуйста, очередная уязвимость в #glibc, эксплуатируемая через #suid бинари.

Писал, и еще раз повторю, suid бинари существенно хуже, чем висящий на unix pipe демон, потому что их можно запускать в разном окружении, стараяcь задеть функции, до которых демон просто не дотянется, потому что работает в хорошо известном начальном окружении.

"Проблема возникает из-за ошибки при попытке вывода через макрос SYSLOG_HEADER слишком длинного имени приложения" - вот ровно про это речь, потому что, если это не приложение, а демон, то его имя известно заранее.

Ну и особенно хочется поржать над

"This vulnerability was introduced in glibc 2.37 (in August
2022) by the following commit:
...
and was also backported to glibc 2.36 because this commit was a fix for another, minor vulnerability in __vsyslog_internal() (CVE-2022-39046, an "uninitialized memory [read] from the heap")"

Пока чинили одну уязвимость, тут же добавили вторую, ага.

#cross

https://nixcademy.com/2024/01/30/cross-compilation-with-nix/

Годный текст про то, что кросс-компиляция - это сложно, но если сделать "правильно" (оценочное суждение), то будет просто.

Правильно - предлагается использовать мета-пакетную систему, типа nix/guix/ix.

К тексту могу добавить, что у меня кросс-компиляция сделана гораздо проще (для пользователя), и несколько сложнее внутри, поэтому у меня можно на любой конечный артефакт написать ix build bin/coreutils --target=darwin-arm64, и оно просто будет работать.

Еще там есть табличка, откуда в куда можно кросс-компилировать в nix, я тут похвастаюсь, что у меня в ней все галочки зеленые, в отличие от.

КДПВ как бы намекает нам, что я снова обращаюсь к своим читателям, с просьбой закинуть на патреон поделиться ссылкой на канал, если он вам, конечно, нравится!

#rust #rant

Много раз слышал, что, дескать, interop Rust в/из С/С++ "хороший", и что он "лучше", чем другие реализации.

Плюньте в того, кто вам такое скажет, потому что он врет.

Interop Rust совершенно отвратительный, он построен исключительно на грубой силе.

Устроен он примерно так - для всех структур, которые ты хочешь использовать cross language, ты садишься, и меряешь все смещения и все размеры каждого элемента. После чего, по сути, вручную, или с небольшой автоматизацией, описываешь ffi вызовы.

Это, конечно, дичь, потому что вот авторы Rust interop с libc вот так измерили все линейкой, а потом оказалось, что им попалась библиотека, которая похожа на musl, но бинарно с ней не совместима. Хотя совершенно совместима на уровне API - все те же заголовки, с точки зрения C/C++ компилятора все на месте, и все работает.

Но вот если эту библиотеку позвать из Rust, то все взрывается самым интересным образом. Потому что interop "фальшивый", и не парсирует C/C++ заголовки, с учетом системного C ABI.

А запустить какой-нибудь codegen, который бы распарсил настоящие заголовки во время сборки - это, конечно, сделать код зависимым от какой-то там libc, и на такое пойти никто не может.

Я, на самом деле, говорю про две несвязанные друг с другом проблемы в musl (и вокруг musl):

* первая связана с тем, что в musl 1.2.5 удалили заглушки для 64-битных функций, которые работают с файлами. https://git.musl-libc.org/cgit/musl/commit/?id=246f1c811448f37a44b41cd8df8d0ef9736d95f4 Rust на версию musl не смотрит (или не смотрел), и считает, что эти функции в ней всегда есть.

* вторая - это уже результат моих издевательств над musl. Я выпилил из musl заглушки про dlopen, и сделал свою реализацию - https://github.com/pg83/dlopen/blob/master/dlfcn.h, она нужна для эмуляции динамического связывания в рамках одного статически слинкованного бинаря. Понятное дело, что ABI этой реализации не совместим с тем, что ожидает Rust от musl.

В итоге, мне пришлось написать 2 прокси, из того, что есть на самом деле, в то, что ожидает Rust:

https://github.com/pg83/ix/blob/main/pkgs/lib/musl/compat/compat.c (https://github.com/pg83/ix/blob/main/pkgs/lib/musl/compat/compat.c#L8 - вот в корректности этой строчки я не уверен, потому что функция open() - "волшебная", она умеет быть запущенной от разного количества аргументов)

И https://github.com/pg83/ix/blob/main/pkgs/lib/dlfcn/abi/fakes.c

Interop такой interop.

Чет ору.

Вышла новая версия Damn Small Linux, после 10 лет небытия.

Прошлая версия весила 50 мегабайт, новая - 650. Такие дела.

https://www.damnsmalllinux.org/
https://www.opennet.ru/opennews/art.shtml?num=60538

Немного довольно очевидных мудростей от PG.

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

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

Самый очевидный метод убедить себя в том, что решение существует, это, конечно, получить хоть какое-то решение задачи.

Самое всратое, тупое, работающее на твоем ноутбуке, и не работающее больше нигде, но решение. Сколько угодно кривое, косое, и которое не может пойти в прод по куче причин.

Хороший пример - https://t.iss.one/itpgchannel/1605

Или утащу случай с работы.

Как-то мне нужно было сделать upver версии gdb для нашей инфраструктуры. gdb не обновлялся много лет, и вообще говоря, было неочевидно, что можно вот так взять новый бинарник с новой мажорной версией, и он возьмет, и заведется.

Поэтому, прежде чем бросаться и строить постоянное сооружение, я пошел и построил херобору - взял новую сборку из какой-то убунты. Эта сборка, конечно, не очень работала в нашей инфре, поэтому я положил рядом с бинарником какие-то недостающие .so со своей рабочей тачки, переписал динамический загрузчик в исполняемом файле, потому что glibc тоже пришлось положить рядом, положил рядом какие-то данные из ncurses, написал враппер, который бы выставил все пути для поиска локальной копии библиотек, упаковал всю эту херобору в tgz, и отправил в условный "testing" (на самом деле, "варить плашку", но это мало кому чего-то скажет).

Благодаря этой хероборе я сумел прикинуть масштаб проблем, и понял, что, в принципе, это подъемная задача, и начал ее "отливать в граните".

(работала ли эта херобора в нашем настоящем проде, история стыдливо умалчивает)