RADARE CUMS WITH ABSOLUTELY NO WARRANTY

Будни #bootstrap #vendor

Собирал тут себе rizin. Не то что он мне очень нужен, как обычно, увидел в списках на обновление, и решил, что оно мне надо.

Хотел было коротенько написать, что сборка сделана очень по уму - поддержка статической сборки со всеми плагинами из коробки, релоцируемый бинарь, ну и de-#vendoring хорошо сделан.

Но черт меня потянул посмотреть, что же это вообще такое...

https://rizin.re/posts/faq/:

Помимо всякого bullshit про заведение code of conduct, я там наткнулся на прекрасное:

"We started efforts of cleaning the source code from offensive phrases and comments. In addition, we will put efforts in creating a more inclusive and diverse community and welcome new contributors"

Тут, конечно, запахло жареным.

На удивление годный топик на LOR про эту тему - https://www.linux.org.ru/news/development/16060831

Ну и на reddit неплохо - https://www.reddit.com/r/ReverseEngineering/comments/k996jq/rizin_fork_from_radare2/

TL;DR - часть команды устала от бесконечных подколок на гейско-анально-фекальную тематику, хехе.

Ссылка на fortunes, которые ранее выдавала radare2:

https://github.com/radareorg/radare2/pull/17980/files
https://github.com/radareorg/radare2/pull/17980/files#diff-00c5297b25daa28f9c6b47774991c52e3f599a89fa8b735f51e34c11e30d9821
https://github.com/radareorg/radare2/blob/a335247dacde918d027b776cea13bba20238de8c/doc/fortunes.nsfw

Nobody can hear your calls for help
There's someone under your bed awaiting

I like to suck nibbles and make hex.
ASLR stands for Age/Sex/Location/Reverser.
I script in C, because fuck you.
Don't masturbate at me
Do you want to see my internals? [Y/n]
The Security Glory Hole

А вот, например, как выглядят пути к файлам: https://github.com/radareorg/radare2/blob/master/libr/anal/flirt.c

Слушайте, ну мне тоже нравится гачимучи тематика(а кому не нравится? А видели, кстати, Херрингтона в ящике? https://medialeaks.ru/2806ndi-str-billy-herrington-fake/), поэтому, в целом, мне бы было норм, но я прекрасно понимаю, почему всяких неженок это может задеть, да.

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

"Компания GitLab планирует в сентябре внести изменения в правила использования сервиса, в соответствии с которыми проекты, размещаемые на хостинге GitLab.com бесплатно, будут автоматически удаляться, если в течение 12 месяцев их репозитории будут оставаться неактивными"

Какие бы я отсюда сделал выводы?

Как минимум, что компания gitlab не имеет глобального key-value стора, для хранения коммитов(для дедупликации). Потому что в нормальной модели(когда тебе не приходится материализовать git репозиторий на диске для работы с ним) форк не должен стоить почти ничего.

Особенно хорошо эта новость смотрится на фоне призыва к отказу от github - https://sfconservancy.org/blog/2022/jun/30/give-up-github-launch/

#vendoring #vendor #npm

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

В копилочку темы про пользу дистрибутивов и их мейнтейнеров.

#openssl, конечно, кусок говна.

Вот bsdtar, слинкованный с nettle(или mbedtls, там столько же):
-r-xr-xr-x 1 ix 1000 3792552 Aug 5 11:55 /ix/store/PTsFUUKyVXAHASCY-bin-bsdtar/bin/bsdtar

А вот с openssl:
-r-xr-xr-x 1 ix 1000 6849040 Aug 5 15:07 /ix/store/YJVZIQjBFUSJ4XX3-bin-bsdtar/bin/bsdtar

Причем я проверил, что с mbedtls и nettle никаких опций, по сравнению с openssl, не выключено.

Наверное, с openssl приехала какая-нибудь фабрика, которая влинковала в себя весь код openssl.

К сожалению, openssl - это common denominator, почти весь код поддерживает или openssl, или еще что-нибудь, и вот это что-нибудь - всегда разное.

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

(кроме довольно редких случаев по типу bsdtar)

Кстати, обратил внимание, что там, где я делаю выбор в пользу openssl, Arch часто делает выбор в пользу gnutls. Интересно, это совпадение, или у них есть какая-то политика на этот счет?

Тут вот на реддите обсуждают новый-кленовый компилятор питона.

https://www.reddit.com/r/Python/comments/w7vlim/i_made_a_python_compiler_that_can_compile_python/

https://github.com/Omyyyy/pycom/tree/main

Окинул это взглядом, что имею сказать:

* https://github.com/Omyyyy/pycom/blob/main/src/pycom/compiler.py - по сути, это жалкая пародия на cython, выигрыш за счет выноса control flow в сишечку.

* Из питона поддерживается всего ничего, код "a = 1; a = 'x'" никогда с таким подходом работать не будет.

Короче, какая-то пионерская поделка, но, блин, 1К звезд на гитхабе! 1К, Карл!

У реально работающего cython - 7K. https://github.com/cython/cython

Куда катится мир?

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

Две новости про шифрование, хорошо идут вместе.

Я, конечно, считаю всю эту тему хайпом и отмывом исследовательских бабосов, потому что:

* Реальное железо, которому это будет релевантно, появится не при моей жизни.

* КМК, пространство алгоритмов в этой области исследовано так себе, и совершенно непонятно, почему вот такое фиаско не случится снова.

Обновлял libwebp, минорная версия.

Судя по всему, webp начала зависеть от библиотеки с тредами, или эту зависимость просто явно прописали, или случилась какая-то дичь, это же #cmake.

Это не то чтобы очень важно, но в экспортных cmake файлах появилась вот такая запись:

"set_target_properties(WebP::webp PROPERTIES
INTERFACE_INCLUDE_DIRECTORIES "${_IMPORT_PREFIX}/include;${_IMPORT_PREFIX}/include"
INTERFACE_LINK_LIBRARIES "Threads::Threads"
)"

Не то чтобы это должно было быть хоть сколько-то важно, но это сломало сборку QT, каким-то нетривиальным образом:

"- Found OpenSSL: /ix/store/3YPdIxQVL9oMNgXL-lib-openssl-3/lib/libcrypto.a (found version "3.0.3")
-- Found WrapOpenSSLHeaders: /ix/store/3YPdIxQVL9oMNgXL-lib-openssl-3/include (found version "3.0.3")
CMake Error at /ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtPublicTargetHelpers.cmake:257 (set_property):
Attempt to promote imported target "Threads::Threads" to global scope (by
setting IMPORTED_GLOBAL) which is not built in this directory.
Call Stack (most recent call first):
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtPublicWalkLibsHelpers.cmake:252 (__qt_internal_promote_target_to_global)
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtPublicWalkLibsHelpers.cmake:225 (__qt_internal_walk_libs)
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtFindPackageHelpers.cmake:12 (__qt_internal_walk_libs)
/ix/store/BSYeU5Bd9S8IYSLe-lib-qt-6-base/lib/cmake/Qt6/QtFindPackageHelpers.cmake:181 (qt_find_package_promote_targets_to_global_scope)
src/imageformats/configure.cmake:19 (qt_find_package)
src/plugins/imageformats/CMakeLists.txt:9 (include)"

cmake - это треш, угар, и содомия, а сборочные скрипты QT для cmake - это треш в квадрате.

Что значит это сообщение об ошибке, я не понял, починил по рабоче-крестьянски: https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/webp/ix.sh#L17-19

Кстати, с cmake сборка webp и так не сильно дружила, экспортные файлы она клала куда-то не туда: https://git.sr.ht/~pg/ix/tree/main/item/pkgs/lib/webp/ix.sh#L14-16

#vendoring #vendor

А иногда люди очень смешно(нет) косячат, когда занимаются ручным(без автоматизации) вендорингом(а в мире С/С++ по другому и не бывает).

Вот, например, автор mold предусмотрел использование некоторых библиотек из системы, типа xxhash, и я этим воспользовался - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/mold/ix.sh#L25

Но, что самое интересное, даже с выставленным этим флажком он продолжает брать заголовок xxhash.h у себя, а не из системы, при этом inline часть xxhash получается его версии, а non-inline - из системы.

Как я это понял?

Я стараюсь при де-вендоринге удалять проблемный код - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/mold/ix.sh#L36

Ну и дальше сборка попала на то, что не могла найти заголовок - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/mold/ix.sh#L43, в системе он не по тому пути лежит.

В случае xxhash это не очень-то и страшно, потому что оно почти целиком inline, а вот в случаях, когда код размазан между заголовком и .c файлом такое может доставить прилично хлопот.

Как понять, что у компании дохуя денег, и что их вот вообще некуда девать?

Если компания:

* Пытается пропихнуть свою вполне обыкновенную шину в ядро, аргументируя это несуществующими преимуществами в performance

* После неудачи пыдается запилить это в виде никому не нужного out of tree модуля https://github.com/bus1/bus1 #kdbus

* Потом пишет супер-эффективный(наверное, на самом-то деле эту херню никто не компилировал, не то что не запускал) https://github.com/bus1/dbus-broker, который должен научить уметь эту шину в 1KK RPS, хотя ей, по всем измерениям, достаточно и 1RPS

* А в финале(?) говорит "а давайте запилим что-нить на current hype language под этой umbrella" https://www.phoronix.com/news/BUS1-r-linux

То у компании совершенно точно дохуя денег, которые некуда девать.

Я таки научился решать эту проблему без bc от busybox.

Нет, не починил гнутый, а нашел еще одну реализацию, которая заявляет, что совместима со всеми известными реализациями - https://git.yzena.com/gavin/bc

Кстати, от того же #gavin, который написал классный текст про статическую линковку, и от того же #gavin, который придумал свою OSS лицензию для борьбы с #copilot.

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

Ядро с этим bc прекрасно собралось, и работает.

В комментариях как раз обсуждали landlock, и на тебе, Justin подогнала gnu make + landlock: #justine

https://justine.lol/make/

TL;DR; - make сам ограничивает свои ноды выполнения по тому, куда им можно писать и что можно читать.

ЖЫР:

"To demonstrate this, I've configured this repository to compile 448 .c files which are linked into 40 executables. Building 448 files in 448 different sandboxes takes:

3.0 seconds with Make
11.6 seconds with Bazel"

Тут мы ее, конечно, поправим, что в Bazel и прочих ya/buck/etc дело не только в контроле зависимостей, а еще и в том, как они проверяют необходимость пересборки(content addressable store, чего gnu make не умеет и никогда не будет уметь).

Ну и, видимо, в bazel executor написан на java, и тормозит при fork + exec, поэтому 500 небольших .c файлов имели большой overhead.

Уверен, что executor на C++(как в ya, например), или даже на Go(как у меня) справились бы не хуже, чудес же не бывает.

Поэтому тут Жастин я ставлю жирный минус, она или не разобралась, или троллит, или ищет дешевый PR для своего решения.

Более четко поясню свою мысль.

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

Говорить что проверка зависимостей ускорилась в разы по сравнению с Bazel - методологически некорректно, предложенное измерение этого не показывает.

Медленно продираюсь через сборку chromium, и она меня, конечно, очень бесит.

Пока как-то так:

"[11727/51727] CXX obj/third_party/dawn/src/dawn/native/sources/PipelineLayoutVk.o
[11728/51727] CXX obj/third_party/dawn/src/dawn/native/sources/DeviceVk.o
[11729/51727] CXX obj/third_party/dawn/src/dawn/native/sources/FencedDeleter.o
ninja: build stopped: subcommand failed.
subcommand error: [/ix/store/JXJCJ6NtAEXKZFAY-bin-chromium/touch sh -s] failed with exit status 1"

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

Например, он полагает, что libc идет из системы, и он полагает, что это glibc.

Поэтому, блин, сраный nasm, который он тоже вендорит, оказывается скофигурен под glibc, и не собирается с musl, а вот стоковый nasm, после запуска своего же configure - собирается. Для меня - это повторение уже сделанной большой работы, по запуску того или иного инструментария в моей среде.

Кстати, список патчей от alpine linux, для сборки под musl - https://git.alpinelinux.org/aports/tree/community/chromium?h=master

Опять же, chromium считает, что mesa и драйвера для 3d идут из системы, а vulkan loader он использует свой, собирает свои же компиляторы шейдеров, и так далее.

Завязки на сборку с x11, раскиданные всюду.

Причем, что интересно, если взять их сборку для внешних людей, то завязки на X11 нет - https://android.googlesource.com/platform/external/swiftshader/+/refs/heads/master/src/WSI/CMakeLists.txt#35

А в сборочном файле "для себя" - есть. https://android.googlesource.com/platform/external/swiftshader/+/refs/heads/master/src/WSI/BUILD.gn#37

Сейчас затык в том, что загрузчик для vulkan они хотят свой, и он как-то не очень совместим с тем, с которым я собирал mesa.

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

Но бесит это, конечно, люто и бешено.

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

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

#npm не нужен

Вот просыпаешься такой, в прекрасном настроении, а тут война авторы swift решили его переписать на swift. #bootstrap

https://forums.swift.org/t/implementing-parts-of-the-swift-compiler-in-swift/59524

Треш, угар, содомия.

Я, конечно, не смог удержаться. https://forums.swift.org/t/implementing-parts-of-the-swift-compiler-in-swift/59524/33

Я уже как-то писал, что по сборочному графу можно много понять про собираемый софт. #jpeg_xl

Например, когда одна библиотека требует буквально вчера вышедшуюю версию какой-то другой библиотеки, которую пишет Гугл, то легко можно понять, кто там пишет #JpegXL.

https://git.sr.ht/~pg/ix/commit/11dc857512d68161153005fe8e27fff243fcd855

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

https://en.wikipedia.org/wiki/JPEG_XL

Я тут какое-то время обдумывал мысль, не стоит ли мне как-то расслабить булки свою позицию про плагины #plugins, и про код, загружаемый в адресное пространство процесса.

Например, разрешив писать плагины для какого-то безопасного представления, типа #wasm.

В целом, идея звучит здраво, скажем, более здраво, чем загрузить случайную .so в себя, но, как мне кажется, пока недостаточно здраво:

* Если ты влинковываешь JIT в себя, то у тебя, скорее всего, поверхность взаимодействия с внешним кодом увеличивается, а не уменьшается. А в то, что этот jit будет без багов, я не очень верю.

* wasm пока довольно lightweight, но почему он через 5 лет не станет очередной JVM, не очень понятно. Стали ли бы вы к себе влинковывать JVM, чтобы безопасно исполнять плагины?

* Даже если предположить, что JIT будет не влинкован в каждое приложение, а будет общесистемный демон, который по bytecode будет возвращать объектный код, то, все равно, такой объектный код все равно опаснее, чем интерпретация, или запуск в отельном процессе.

Короче, хорошо, но, КМК, недостаточно хорошо.

Какой-нибудь очень простой wasm-интерпретатор, для не критичных к CPU блоков кода, мне кажется более интересным.

Ну и, если вы браузер, и уже притащили к себе wasm jit, то почему бы вам не скомпилировать просмотрщик PDF в WASM? Вот в этом не вижу ничего плохого, только хорошее. Или, если пофантазировать, то отказаться от текущей модели браузеров(процесс на страницу), и просто весь браузер собрать в безопасный wasm.

А лично я пока продолжаю считать, что отдельный процесс на плагин - наше все.

#maskray, #mold

Коллега никак не успокаивается(и это хорошо!), написал план про ускорение LLD.

https://discourse.llvm.org/t/parallel-input-file-parsing/60164

Речь идет про распараллеливание построения таблицы символов.

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

КМК, тут коллегам нужно уже перестать сцать менять форматы файлов, и подумать на предмет непарсируемых .o/.a файлов, например, используя flatbuffers, или capnproto.

Но, к сожалению, в мире дедов с ABI С/C++ это малореалистично.

https://matt-rickard.com/the-unreasonable-effectiveness-of-makefiles

https://lobste.rs/s/sq9h3p/unreasonable_effectiveness_makefiles

Тут вот коллега восторгается, как же хороши Makefile, и как же они классно умеют выполнять DAG.

"Does not manage the state itself. No database of file modification times, checksums, or build output files that could cause bad states to happen. Instead, make just compares the file modification times of the outputs to the inputs."

Знаете, мне это все кажется аргументацией в стиле "оно случилось именно так, потому что никак иначе случиться не могло". Слабый атропный принцип, да.

Такой аргумент, к сожалению, ничего не объясняет.

В доказательство предлагаю вам пофантазировать, как бы выглядел тулинг вокруг сборки, и выполнятор DAG, если бы авторы Unix сделали не только mtime, а какую-нить скользящую чексумму, доступную через вызов stat(), для каждого файла в системе.

А make - это просто тот выполнитель DAG, который мог быть сделан с помощью куцего posix api, без дополнительных усилий.

Он был неплох, для своего времени, и не более того.

Пока виарщики думают как трекать руки и выкинуть наконец эти громоздкие контроллеры, китайцы все давно придумали. И не в метаверсе, а в кожаной вселенной.

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

Недавно вышли новые binutils. И, в связи с этим, у меня есть несколько не очень связанных тем, но про binutils!

1) "В утилиту nm добавлена опция "--no-weak" ("-W") для игнорирования weak-символов."

Казалось бы, мелочь, но. В данном случае компилятор и линкер от проекта GNU следует за проектом LLVM/Clang, причем они решили даже не коверкать название опции, как это было с -fcolor-diagnostics, а взяли ее as is. Я, конечно, считаю это очень важным, потому что проекту GNU я желаю или радикально поменяться, или уже загнуться.

2) Давно хотел рассказать про de-vendoring binutils, который я проделал.

binutils - это набор из 6 рекурсивных configure скриптов, которые вызывают друг друга, и собирают 3 бинаря да 2 библиотеки.

Это очень всрато, и я бы не стал это трогать, но:

* perf требует одну из этих "недокументированных" библиотек - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/perf/unwrap/ix.sh#L22 причем эта недокументированная библиотека не заботится об API, поэтому сломалась при обновлении - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/perf/unwrap/ix.sh#L61

* понадобилось дотащить нетривиальный параметр до одного из Makefile, в случае рекурсивных configure из коробки это не делается - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/ld/ix.sh#L24

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

Мои binutils - https://git.sr.ht/~pg/ix/tree/main/item/pkgs/bin/binutils/ix.sh Параллельность сборки так выше, чем у ad hoc запуска configure из configure.

3) А вы знали, что в проекте GNU есть две конкурирующих реализации ld/as/etc? Это elfutils, и binutils. Причем про binutils знают все, а вот про elfutils даже я узнал всего год назад, хотя, казалось бы, сколько лет с Linux.

Историю появления elfutils я пока не раскрутил, но там явно что-то интересное.

4) Одна из развендоренных библиотек называется libiberty. Вопрос - почему у нее такое странное название, и что оно означает?

https://www.phoronix.com/news/Glibc-2.36-EAC-Problems

Треш, угар, содомия.

#glibc нарушили базовое предположение про совместимость, что код, собранный со старой glibc на старом Linux, продолжит работать и на новых Linux. #abi

Очень забавно, как Миша крутится, как уж на сковородке, пытаясь представить это как fault от valve:

"DT_GNU_HASH has been around for a decade and a half and can lead to much faster linking and loading times. Most Linux distributions and open-source software have been happily using DT_GNU_HASH for years"

"Ну, все же уже 10 лет используют новый хеш" (ну а все остальные - ССЗБ, видимо)

"With Glibc 2.36, DT_HASH no longer gets set since they dropped "--hash-style=both" since the DT_GNU_HASH is superior, most systems should just be using that, and eliminating the DT_HASH section saves about 1% or 16kB of space for the Glibc shared object"

Серьезно? Сука, сэкономили 16 килобайт в .so?

"Now we'll see what happens with upstream GNU C Library developers around this or if they'll wait it out and punt the ball into Epic Games' court to switch from depending upon DT_HASH to the DT_GNU_HASH that has been widely used on Linux systems for over a decade"

Не, ну раз 10 лет все(?) уже успешно используют новую фичу, то те, кто использует старую - ССЗБ, и их, конечно, можно послать.

Авторы glibc - #errogant(e intended) красноглазые пенсионеры, ничего они не откатят:

https://sourceware.org/pipermail/libc-alpha/2022-August/141304.html

- The choice to have DT_HASH is with the distributions. If this breaks specific applications then those developers need to engage with the ecosystem or adapt their software.

Errogant, потому что они, на голубом глазу, заявляют, что не ломают ABI:

"We aren't breaking ABI when we remove the PLT, remove the old HASH, or other Linux ELF change"...

Нет слов.