Интересно, зачем в современных 64-битных системах нужна защита памяти?

Казалось бы, поместил программу и ее данные по рандомному адресу, и тогда злоумышленник просто не сможет ее найти во всем адресном пространстве, потому что, каждый раз когда он будет промахиваться, его будут убивать, ну и потому что 64 бит - это ОЧЕНЬ много.

Я понимаю, что современные CPU используют меньше 64 бит, и что надо как-то защищать небольшую часть операционной системы, которая являлась бы gate для входа в нее, но, все же?

Действительно годные советы от коучей, наконец-то.

Programmer memes

https://www.davd.io/posts/2024-03-20-kubernetes-and-back-why-i-dont-run-distributed-systems/

Очередной rant от человека, который не понял, что распределенные системы - это не "проще", а "надежнее", при этом они требуют больше усилий, чтобы только держаться на плаву.

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

https://www.swift.org/blog/adwaita-swift/
https://github.com/AparokshaUI/adwaita-swift

Чуваки запилили биндинги gtk + adwaita к swift.

Идея прикольная, потому что не на С с Vala же gui программирвать, и не на Python.

Я вот для себя совершенно точно знаю, что, если я захочу запилить gui на gtk, то я возьму golang.

Swift кажется тоже годной альтернативой.

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

В копилочку. #fork

О-че-редь. Огромная очередь. За любым популярным проектом. Стоит лишь раз ошибиться.

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

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

Ну вот захотел бы Редис продаться за деньги большому дяде? Но зачем это большому дяде, если через год он получит это же, но бесплатно, и развивать будет не один, а в несколько компаний? Так к форку и у сообщества доверия больше, чем если бы его пилила одна большая компания.

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

https://www.opennet.ru/opennews/art.shtml?num=60860 просто оставлю тут очередную #cve про #ksmbd.

(а некоторые меня спрашивают, почему я отказываюсь использовать NFS из ядра)

https://www.phoronix.com/news/Inkscape-Switches-To-GTK4

Inkscape как-то очень быстро и решительно запилили поддержку gtk4.

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

Видимо, здесь дело в разнице между сильно типизированным языком (С++), и слабо типизированным (С).

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

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

#xz_gate

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

Не менее прекрасно и то, как эксплоит был найден:

https://mastodon.social/@AndresFreundTec/112180406142695845

"I was doing some micro-benchmarking at the time, needed to quiesce the system to reduce noise. Saw sshd processes were using a surprising amount of CPU, despite immediately failing because of wrong usernames etc. Profiled sshd, showing lots of cpu time in liblzma, with perf unable to attribute it to a symbol. Got suspicious. Recalled that I had seen an odd valgrind complaint in automated testing of postgres, a few weeks earlier, after package updates.

Really required a lot of coincidences"

А что же #stal/ix?

А stal/ix эксплоиту не подвержен, по двум причинам:

* IFUNC не работает со статической линковкой. Это ограничение не принципиально, можно и завести, но всем лень.

* Более интересная причина - потому что я проактивно борюсь с такого рода возможностью, когда сумасшедший мейнтейнер может учудить, и не беру tgz, сваренные человеком, а беру tgz, сваренные системой контроля версий (прямые ссылки на архивы бранчей и коммитов) - https://xn--r1a.website/itpgchannel/93.

UPD: https://github.com/tukaani-project/xz - репу закрыли :(

github - контора пидорасов. Дважды пидорасов.

Потому что, по сути, они закрыли источник кода без наложенного вредоноса (https://github.com/tukaani-project/xz). Ну и сломали большое количество CI по всему миру.

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

В Rust std нет семафоров, их выпиляли давным-давно. Решил поискать готовое, но лучше бы сразу сделал велосипед.

Зато нашел вот такие перлы. Рукалицо, дайте мне это развидеть.

Всегда проверяйте чужой код (даже если он из std - тоже проверяйте).

Истории про мою home #lab.

Заебался я на самом деле с этой загрузочной флешкой.

Много чего было, расскажу про две проблемы.

Первая - то, что root fs пытается настроиться до того, как проинициализирован usb controller.

Сука, это леденящий душу пиздец.

GRUB загружает ядро Linux, передает в загрузчик ядра partition uuid, а потом Linux не может найти этот partition uuid, потому что разделы на флешке еще не пронумерованы, потому что система их еще не нашла.

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

Дебажил это реально несколько часов.

Решение?

Слушайте, вот как бы эту проблему решил нормальный разраб? Я бы написал там какой-то retry, с exponential backoff, пытаясь примонтировать rootfs до того момента, когда инициализация драйверов не будет полностью завершена.

Конечно, это было бы слишком просто, и работало бы слишком хорошо, поэтому это явно не Linux-way.

Заботливые кернел-какеры предлагают вот такую опцию - https://www.linuxtopia.org/online_books/linux_kernel/kernel_configuration/re58.html. Ну, типа, сделайте sleep 20, наверняка за это время все usb устройства будут найдены.

Леденящий душу пиздец. Программирование многопоточных программ на sleep, ага.

Истории про мою home #lab.

И вторая проблема - а как написать правильную конфигурацию GRUB, чтобы не надо было заморачиваться с probe всего и вся?

Флешка может использоваться на разном железе, и не всегда она будет hd0.

В итоге, решил я это так:

* На первой партиции, в которой лежит EFI, я кладу же и сам GRUB, с его конфигом, который устроен вот так:

https://github.com/pg83/lab/blob/master/lab/services/mk/boot.sh#L19-L28

set root=hd0,2
configfile /etc/grub.cfg
set root=hd1,2
configfile /etc/grub.cfg
set root=hd2,2
configfile /etc/grub.cfg
set root=hd3,2
configfile /etc/grub.cfg
set root=hd4,2
configfile /etc/grub.cfg

А дальше, на второй партиции лежит уже настоящий конфиг, который адресован относительно root:

https://gist.github.com/pg83/7941d82e39c6a019ce184e01572ed62d

GRUB тут себя ведет, как POSIX sh без set -e, то есть, просто пропускает все неуспешные команды, пока не сможет попасть в реально существующий конфиг.

Работает like a charm, загружается на любом моем конфиге.

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

Истории про home #lab.

Пока я переводил хосты на новую схему загрузки (с флешкой в качестве /dev/root), мне несколько раз пришлось пошатать #etcd.

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

Два раза все прошло хорошо, на третий раз я осмелел, и решил устроить ученьки с disaster recovery.

Взял, и под живым инстансом etcd забил его базу из /dev/random, дождался, пока это все не дошло до кластера, ребутнул, переналил на новую схему, поднял пустой инстанс etcd.

В общем, провел пару часов за чтением документации, кластер оживил.

Но это было несколько сложнее, чем я ожидал.

Потому что кворум из двух машин перевел этот третий инстанс в состояние "never again", то есть, пометил его id как сломанный навсегда, и отказывался с ним иметь дело даже после переналивки.

Выяснилось, что надо вручную удалить из кластера этот id, и добавить новый инстанс с новым id.

Зачем так сложно, и зачем эта процедура отличается от предыдущей, не очень понятно.

Зато, КМК, теперь я получил некоторый опыт, и уверенность, что, в случае чего, данные в etcd я не проебу, и мне теперь не сташно класть туда какие-то master/original данные, а не только легко восстановимые копии.

Будни #bootstrap

Я настолько задолбался, что сел, и запилил свой велосипед.

Его формат - максимально простой.

Это пожатый \n-delimited json, примерно такого содержания:

{"type": "file", "data": base64(data), \
 "path": "a/b/c.x", "flags": ["exe"]}
{"type": "dir", "path", "x/y/z"}
{"type": "symln", "path": "a", "to": "c/d"}

Да, да, это текстовый формат (не так, как в дурацком nar, а действительно текстовый):

* не нужно велосипедить парсер

* для отладки (поиска отличий) достаточно diff

* парсеры и сериализаторы json настолько быстрые (https://github.com/simdjson/simdjson), что даже оставляют за собой всякие бинарные форматы, типа protobuf. Ну потому что json мы перекладываем чаще всего, вот он и соптимизирован в хламину

* после сжатия каким-нить нормальным компрессором (я взял zstd -10), вы не увидите разницу между моим форматом, и специализированным бинарным, потому что все ключи часто повторяются, и займут примерно 0 байт, ну а то, что compress(base64(data)) ~~ compress(data) - факт довольно очевидный.

https://github.com/pg83/ix/blob/main/pkgs/bld/pzd/scripts/ser.py - вот, например, компрессор
https://github.com/pg83/ix/blob/main/pkgs/bld/pzd/scripts/des.py - а вот декомпрессор

Да, на python, потому что на golang заняло бы в 2 раза больше строк, а работало бы так же, потому что json в python соптимизирован в хлам, но требовало бы бутстрепа golang, а python у меня есть всегда.

Вот эти вот несчастные 50 строк кода:

* работают на полтора десятичных порядка быстрее, чем мой предыдущий вариант на shell, который на каждый файл зовет chown/chmod (чтобы привести все к одному набору флагов). Нет нужды оптимизировать, потому что стало о-малое от времени на download всего этого дела.

* решили вообще ВСЕ накопившиеся у меня проблемы с этим форматом

Надо было сразу не бояться велосипедить, и сделать все по уму!

Назвал я его, конечно, .pzd, от Packed ZstD

Вышли coreutils 9.5 https://www.opennet.ru/opennews/art.shtml?num=60872

Все бы хорошо, но:

"Сокращено время запуска утилиты sort за счёт прекращения динамического связывания с библиотекой libcrypto в ситуациях, когда не указана опция -R"

Sooqa, эти люди стали загружать openssl через dlopen, потому что, видите ли, их коллеги по цеху не смогли запилить достаточно быстрый динамический загрузчик.

Поэтому мы не будем линковаться с ним в процессе сборки, но обязательно позовем в runtime, со всеми вытекающими (код будет работать по разному у тех, кто поставил себе openssl, а кто - нет)

Я как-то косвенно упомянул #heirloom https://heirloom.sourceforge.net/ , это аналог coreutils/busybox, но только родом из традиционных UNIX, типа Sun, Caldera.

Очень интересный проект, и он у меня участвовал в процедуре #bootstrap - это когда нужно иметь хоть какие-то версии утилит, для того, чтобы собрать более продвинутые версии утилит.

Ну, типа, configure скрипты gnu grep/awk/diff/patch/sed/etc требуют уже работающих awk/grep/sed/diff/etc.

Раньше, когда я только начинал пилить #ix, я использовал heirloom как "начало начал" - имея только libc, нужно получить хоть какие-то unix тулзы, чтобы дальше собирать что-то еще.

Вот у меня был самый отвратительный shell script ever - https://github.com/pg83/mix/blob/main/pkgs/bld/boot/2/heirloom/darwin/ix.sh#L70-L95

Тут literally описан порядок сборки всяких mkdir/cp/rm, чтобы дальше можно было собрать что-то еще, из поставки heirloom.

Я постепенно заменял этот скрипт на:

* sbase - для базовых утилит, из проекта suckless - https://core.suckless.org/sbase/ (там есть слабенький grep, и sed, который падает в корку)

* minised - https://github.com/bostikforever/minised

* bmake - https://www.crufty.net/help/sjg/bmake.html - реализация make, которую можно собрать через cc *.c https://xn--r1a.website/itpgchannel/82

* и, вот, появилась новая реализация awk, для проекта https://github.com/landley/toybox (https://xn--r1a.website/itpgchannel/145), которая зависит только от C - https://github.com/raygard/wak

Я, конечно, добавил ее в процесс бутстрапа, и отправил этот гадкий скрипт на заслуженный отдых, потому что heirloom больше не участвует в моей процедуре bootstrap!

После этого вашего #xz_gate какие-то хаотические движения во всем open source:

Кто-то обсуждает отказ от xz.

Кто-то пилит способ воспроизвести все окружение, нужное для того, чтобы запустить эту дырень - https://github.com/amlweems/xzbot, прямо https://anekdotov.net/anekdot/all/bspkstvskrnnvsh.htm

кто-то предлагает пострипать лишние зависимости у systemd - https://www.opennet.ru/opennews/art.shtml?num=60912 Наверное, люди уже написали весь важный код, и надо писать не очень важный.

Кто-то пишет большие заметки, пытаясь срубить хайпа на великих (Кен Томпсон с его trusting trust) - https://joeyh.name/blog/entry/reflections_on_distrusting_xz/

Кто-то вендорит xz (https://github.com/Genivia/ugrep):

Making all in lzma/C
  CC       libviiz_a-viizip.o
  CC       libviiz_a-7zAlloc.o
  CC       libviiz_a-7zArcIn.o
  CC       libviiz_a-7zBuf.o
  CC       libviiz_a-7zBuf2.o
  CC       libviiz_a-7zCrcOpt.o
  CC       libviiz_a-7zDec.o
  CC       libviiz_a-7zCrc.o
  CC       libviiz_a-7zFile.o
  CC       libviiz_a-7zStream.o
  CC       libviiz_a-Bcj2.o
  CC       libviiz_a-Bra86.o
  CC       libviiz_a-Bra.o
  CC       libviiz_a-BraIA64.o
  CC       libviiz_a-CpuArch.o
  CC       libviiz_a-Delta.o
  CC       libviiz_a-Lzma2Dec.o
  CC       libviiz_a-LzmaDec.o
  CC       libviiz_a-Ppmd7.o
  CC       libviiz_a-Ppmd7Dec.o

Я вот дернул кофе, и написал этот обзор.